From tias251 at gmail.com Tue Mar 3 09:00:19 2020 From: tias251 at gmail.com (Matthias Perktold) Date: Tue, 3 Mar 2020 10:00:19 +0100 Subject: Compact deconstruction patterns Message-ID: <000201d5f13a$2ac505d0$804f1170$@gmail.com> According to https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, the current proposal is to allow to ways of using records as deconstruction patterns: 1) With nested type patterns: case AddNode(Node left, Node right)) -> ... 2) With nested var patterns: case AddNode(var left, var right)) -> ... I was wondering whether it could make sense to allow to leave out var: case AddNode(left, right)) -> ... This would be especially convenient for nested record patterns. Compare case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... with case Line(Point(x0, y0), Point(x1, y1)) -> ... The consequence would be that the syntax rules for the innermost patterns would more closely resemble the ones for lambda parameters rather than local variables. Note that, there is no risk of ambiguity. Since it appears right after case, it's clear from the context that the whole expression is used as a pattern. The same holds for instanceof patterns. Now I'm sure this idea has already crossed your mind. Did you reject it for any particular reason? Or do you simply want to wait until you are really sure this is something you actually want? I realize this can be added any time in a future release. Thanks, Matthias From brian.goetz at oracle.com Tue Mar 3 11:49:08 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 3 Mar 2020 11:49:08 +0000 Subject: Compact deconstruction patterns In-Reply-To: <000201d5f13a$2ac505d0$804f1170$@gmail.com> References: <000201d5f13a$2ac505d0$804f1170$@gmail.com> Message-ID: <4765D367-34A2-45E2-9495-976D97BDE508@oracle.com> This has come up a few times. There are several reasons to prefer the current approach, most of which stem from the prime directive, ?reading code is more important than writing code.? The argument for the compact version is really ?I can do less typing?, which is a relatively weak motivation when the typing we are saving is the three characters v-a-r. These are variable _declarations_, and variable declarations should look like declarations. `int x` and `var x` look like declarations; `x` looks like a use of an existing variable. (You might point out that we do a similar thing in lambdas, where we use an unadorned name, but the -> token is is a very, very strong indication that these are formals. I don?t think that justification is in play here. Note too that in lambdas you can say `(var x) -> ?` now, and if we had `var` in the language when we did lambdas, we might well have not even supported the more compact `(x,y) -> ?` form at the time. So rather than this being a precedent to emulate, we might choose to view it as a historical inconvenience.) Further, down the road, we intend to have patterns that can actually take input arguments, such as `regex(?a*b*? ?)`. (Please, no syntax bike shedding on this now.) This creates the possibility where the `x` in `Foo.bar(x)` could either be an input parameter, or a constant pattern, or a fresh binding variable ? this is asking a lot of readers. In the end, it comes down to: there is a benefit to being explicit (easier to spot declarations), and an additional cost to being implicit (potential for ambiguities down the road.) The benefit for being implicit is saving the typing of three characters. This seems a pretty easy decision. > On Mar 3, 2020, at 9:00 AM, Matthias Perktold wrote: > > According to > https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, the > current proposal is to allow to ways of using records as deconstruction > patterns: > > 1) With nested type patterns: case AddNode(Node left, Node right)) -> ... > 2) With nested var patterns: case AddNode(var left, var right)) -> ... > > I was wondering whether it could make sense to allow to leave out var: > case AddNode(left, right)) -> ... > > This would be especially convenient for nested record patterns. > > Compare > case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... > with > case Line(Point(x0, y0), Point(x1, y1)) -> ... > > The consequence would be that the syntax rules for the innermost patterns > would more closely resemble the ones for lambda parameters rather than local > variables. > > Note that, there is no risk of ambiguity. > Since it appears right after case, it's clear from the context that the > whole expression is used as a pattern. > The same holds for instanceof patterns. > > Now I'm sure this idea has already crossed your mind. > Did you reject it for any particular reason? > Or do you simply want to wait until you are really sure this is something > you actually want? > > I realize this can be added any time in a future release. > > Thanks, > Matthias > From amaembo at gmail.com Wed Mar 4 05:24:18 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 4 Mar 2020 12:24:18 +0700 Subject: Compact deconstruction patterns In-Reply-To: <4765D367-34A2-45E2-9495-976D97BDE508@oracle.com> References: <000201d5f13a$2ac505d0$804f1170$@gmail.com> <4765D367-34A2-45E2-9495-976D97BDE508@oracle.com> Message-ID: Hello! > This has come up a few times. There are several reasons to prefer the current approach, most of which stem from the prime directive, ?reading code is more important than writing code.? The argument for the compact version is really ?I can do less typing?, which is a relatively weak motivation when the typing we are saving is the three characters v-a-r. For me, this argument doesn't sound convincing. The problem is exactly with reading: you have to read all these noise var's, this makes lines longer for no big reason, your eyes need to make more horizontal movements. The deconstruction (especially the nested one) might include many fields, so it's not just four characters (var + space), but four times the number of pattern variables (16 in the example supplied by Matthias). Also, don't forget about visually impaired (not totally blind) people who set very big editor font having much fewer symbols fitting the screen horizontally. I see the arguments below, and they look more reasonable, but probably it's better to come with design decisions how all possible patterns will look like before releasing the partial feature. Probably there are ways to keep more common patterns shorter while allowing to write more complex patterns. I don't think that we should accept the var syntax solely because otherwise it might collide with the syntax of a future feature, and at the same time ask "no syntax bike shedding" for that future feature. What if the future feature syntax could be adjusted to make the clash impossible? With best regards, Tagir Valeev. > > These are variable _declarations_, and variable declarations should look like declarations. `int x` and `var x` look like declarations; `x` looks like a use of an existing variable. (You might point out that we do a similar thing in lambdas, where we use an unadorned name, but the -> token is is a very, very strong indication that these are formals. I don?t think that justification is in play here. Note too that in lambdas you can say `(var x) -> ?` now, and if we had `var` in the language when we did lambdas, we might well have not even supported the more compact `(x,y) -> ?` form at the time. So rather than this being a precedent to emulate, we might choose to view it as a historical inconvenience.) > > Further, down the road, we intend to have patterns that can actually take input arguments, such as `regex(?a*b*? ?)`. (Please, no syntax bike shedding on this now.) This creates the possibility where the `x` in `Foo.bar(x)` could either be an input parameter, or a constant pattern, or a fresh binding variable ? this is asking a lot of readers. > > In the end, it comes down to: there is a benefit to being explicit (easier to spot declarations), and an additional cost to being implicit (potential for ambiguities down the road.) The benefit for being implicit is saving the typing of three characters. This seems a pretty easy decision. > > > > On Mar 3, 2020, at 9:00 AM, Matthias Perktold wrote: > > > > According to > > https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, the > > current proposal is to allow to ways of using records as deconstruction > > patterns: > > > > 1) With nested type patterns: case AddNode(Node left, Node right)) -> ... > > 2) With nested var patterns: case AddNode(var left, var right)) -> ... > > > > I was wondering whether it could make sense to allow to leave out var: > > case AddNode(left, right)) -> ... > > > > This would be especially convenient for nested record patterns. > > > > Compare > > case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... > > with > > case Line(Point(x0, y0), Point(x1, y1)) -> ... > > > > The consequence would be that the syntax rules for the innermost patterns > > would more closely resemble the ones for lambda parameters rather than local > > variables. > > > > Note that, there is no risk of ambiguity. > > Since it appears right after case, it's clear from the context that the > > whole expression is used as a pattern. > > The same holds for instanceof patterns. > > > > Now I'm sure this idea has already crossed your mind. > > Did you reject it for any particular reason? > > Or do you simply want to wait until you are really sure this is something > > you actually want? > > > > I realize this can be added any time in a future release. > > > > Thanks, > > Matthias > > > From brian.goetz at oracle.com Wed Mar 4 07:55:19 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 4 Mar 2020 07:55:19 +0000 Subject: Compact deconstruction patterns In-Reply-To: References: Message-ID: That?s all fine, but I think you are mischaracterizing the reason we are preferring var? t?s not because we don?t like the alternative. It is because it is the natural Combination of type inference with type patterns. And, given that combination, there is no need to go further in the concision department, and lots of reasons not to. Sent from my iPad > On Mar 4, 2020, at 5:24 AM, Tagir Valeev wrote: > > ?Hello! > >> This has come up a few times. There are several reasons to prefer the current approach, most of which stem from the prime directive, ?reading code is more important than writing code.? The argument for the compact version is really ?I can do less typing?, which is a relatively weak motivation when the typing we are saving is the three characters v-a-r. > > For me, this argument doesn't sound convincing. The problem is exactly > with reading: you have to read all these noise var's, this makes lines > longer for no big reason, your eyes need to make more horizontal > movements. The deconstruction (especially the nested one) might > include many fields, so it's not just four characters (var + space), > but four times the number of pattern variables (16 in the example > supplied by Matthias). Also, don't forget about visually impaired (not > totally blind) people who set very big editor font having much fewer > symbols fitting the screen horizontally. > > I see the arguments below, and they look more reasonable, but probably > it's better to come with design decisions how all possible patterns > will look like before releasing the partial feature. Probably there > are ways to keep more common patterns shorter while allowing to write > more complex patterns. I don't think that we should accept the var > syntax solely because otherwise it might collide with the syntax of a > future feature, and at the same time ask "no syntax bike shedding" for > that future feature. What if the future feature syntax could be > adjusted to make the clash impossible? > > With best regards, > Tagir Valeev. > >> >> These are variable _declarations_, and variable declarations should look like declarations. `int x` and `var x` look like declarations; `x` looks like a use of an existing variable. (You might point out that we do a similar thing in lambdas, where we use an unadorned name, but the -> token is is a very, very strong indication that these are formals. I don?t think that justification is in play here. Note too that in lambdas you can say `(var x) -> ?` now, and if we had `var` in the language when we did lambdas, we might well have not even supported the more compact `(x,y) -> ?` form at the time. So rather than this being a precedent to emulate, we might choose to view it as a historical inconvenience.) >> >> Further, down the road, we intend to have patterns that can actually take input arguments, such as `regex(?a*b*? ?)`. (Please, no syntax bike shedding on this now.) This creates the possibility where the `x` in `Foo.bar(x)` could either be an input parameter, or a constant pattern, or a fresh binding variable ? this is asking a lot of readers. >> >> In the end, it comes down to: there is a benefit to being explicit (easier to spot declarations), and an additional cost to being implicit (potential for ambiguities down the road.) The benefit for being implicit is saving the typing of three characters. This seems a pretty easy decision. >> >> >>>> On Mar 3, 2020, at 9:00 AM, Matthias Perktold wrote: >>> >>> According to >>> https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, the >>> current proposal is to allow to ways of using records as deconstruction >>> patterns: >>> >>> 1) With nested type patterns: case AddNode(Node left, Node right)) -> ... >>> 2) With nested var patterns: case AddNode(var left, var right)) -> ... >>> >>> I was wondering whether it could make sense to allow to leave out var: >>> case AddNode(left, right)) -> ... >>> >>> This would be especially convenient for nested record patterns. >>> >>> Compare >>> case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... >>> with >>> case Line(Point(x0, y0), Point(x1, y1)) -> ... >>> >>> The consequence would be that the syntax rules for the innermost patterns >>> would more closely resemble the ones for lambda parameters rather than local >>> variables. >>> >>> Note that, there is no risk of ambiguity. >>> Since it appears right after case, it's clear from the context that the >>> whole expression is used as a pattern. >>> The same holds for instanceof patterns. >>> >>> Now I'm sure this idea has already crossed your mind. >>> Did you reject it for any particular reason? >>> Or do you simply want to wait until you are really sure this is something >>> you actually want? >>> >>> I realize this can be added any time in a future release. >>> >>> Thanks, >>> Matthias >>> >> From tias251 at gmail.com Wed Mar 4 08:18:33 2020 From: tias251 at gmail.com (Matthias Perktold) Date: Wed, 4 Mar 2020 09:18:33 +0100 Subject: AW: Compact deconstruction patterns In-Reply-To: References: <000201d5f13a$2ac505d0$804f1170$@gmail.com> <4765D367-34A2-45E2-9495-976D97BDE508@oracle.com> Message-ID: <018501d5f1fd$7f74ab30$7e5e0190$@gmail.com> Thank you all for entering into this discussion. > > This has come up a few times. There are several reasons to prefer the current approach, most of which stem from the prime directive, ?reading code is more important than writing code.? The argument for the compact version is really ?I can do less typing?, which is a relatively weak motivation when the typing we are saving is the three characters v-a-r. > For me, this argument doesn't sound convincing. The problem is exactly with reading: you have to read all these noise var's, this makes lines longer for no big reason, your eyes need to make more horizontal movements. The deconstruction (especially the nested one) might include many fields, so it's not just four characters (var + space), but four times the number of pattern variables (16 in the example supplied by Matthias). Also, don't forget about visually impaired (not totally blind) people who set very big editor font having much fewer symbols fitting the screen horizontally. I think the same way. Yes, you would type less characters, but you would also save reading them. Because once you understand that this is a pattern, `var` doesn't add any information, and neither does having it multiple times. > > These are variable _declarations_, and variable declarations should > look like declarations. `int x` and `var x` look like declarations; > `x` looks like a use of an existing variable. (You might point out > that we do a similar thing in lambdas, where we use an unadorned name, > but the -> token is is a very, very strong indication that these are > formals. I don?t think that justification is in play here. Indeed, that's the question here. I'd say a switch expression is also a strong indication, as it spans multiple lines, with each pattern at the beginning of a new line, right after `case`. Patterns used with `instanceof` are probably harder to spot, especially when combined with other expressions using `&&` or `||`. On another note, I see other languages like Haskell or Scala do allow deconstruction patterns without indications like var. That's not to say Java has to do the same, but it shows that this approach can work quite well. At least I never heard that it's hard to tell whether a symbol is referring to an existing variable or declaring a new one. Again, a deeply nested `instanceof` might make things harder in Java. On the other hand, declaring new variables in such a place is probably a bad idea per se, whether you use var or not. Compare if (someFlag && p instanceof Point(var x, var y) && anotherFlag) { ... } With if (someFlag && p instanceof Point(x, y) && anotherFlag) { ... } Here, I would prefer the version with var, but neither is really satisfactory. > Note too that in lambdas you can say `(var x) -> ?` now, and if we had `var` in > the language when we did lambdas, we might well have not even > supported the more compact `(x,y) -> ?` form at the time. So rather > than this being a precedent to emulate, we might choose to view it as > a historical inconvenience.) My proposal is exactly to allow the same kinds of declarations in deconstruction patterns as in lambda parameters. This way, you would not only save typing and reading, but also increase consistency of the syntax. It's interesting that you now seem to favor `(var x) -> ...` over `x -> ...`. Honestly, I would never write a lambda with var, and probably remove the var if I would see one in my codebase. I always thought the reason that you can now use var in lambdas is again consistency, as well as being able to put annotations on lambda parameters without explicitly providing their type. Other than that, var is pretty useless here, so I'm glad we didn't have var at that time. ?? > Further, down the road, we intend to have patterns that can actually take input arguments, such as `regex(?a*b*? ?)`. (Please, no syntax bike shedding on this now.) This creates the possibility where the `x` in `Foo.bar(x)` could either be an input parameter, or a constant pattern, or a fresh binding variable ? this is asking a lot of readers. > In the end, it comes down to: there is a benefit to being explicit (easier to spot declarations), and an additional cost to being implicit (potential for ambiguities down the road.) The benefit for being implicit is saving the typing of three characters. This seems a pretty easy decision. This is interesting, thanks for sharing. With this in mind, I can better understand your point of view. Maybe the best strategy is to require at least var for the moment and pick up the discussion once there is a clear understanding which kind of patterns are going to be supported in the future. Thanks, Matthias From forax at univ-mlv.fr Wed Mar 4 10:18:07 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Mar 2020 11:18:07 +0100 (CET) Subject: Compact deconstruction patterns In-Reply-To: References: Message-ID: <1827066791.1699559.1583317087383.JavaMail.zimbra@u-pem.fr> I think Brian is miles ahead :) that's why you did not understand his answer, let me try to explain the problem and why var/type is the best choice. Let's takes an example, using the syntax you propose, var shape = ... var value = switch(shape) { case Point(x, y) -> x + y; ... }; now we also want to support adding constant as pattern, something like var value = switch(shape) { case Point(0, y) -> y; ... }; obviously, if we support constant, we also need to support variable, so the last code can be rewritten like this by introducing a new local variable x var x = 0; var value = switch(shape) { case Point(x, y) -> y; ... }; And here, i'm sure you have spot the issue, 'case Point(x, y)' is now ambiguous, because whe don't know if x refer to the local variable above or to a fresh new local variable. If you study other languages that have pattern matching, there are 3 possible solutions 1. be clever but ... 2. use a pin operator 3. use var Option 1, we can be clever, in Java, you can not introduce the same local variable twice so 'case Point(x, y)' means that x is the already existing local variable because otherwise, introducing a new fresh local variable will result in an error. But this solution has two drawbacks, the most important, it means that introducing a local variable above a switch (or an instanceof, etc) change the semantics of the switch, not a good property apart if you write code puzzler for a living. The other issue is that it interacts badly with fields. By example, if you have the code class Foo { int x; void m() { var value = switch(shape) { case Point(x, y) -> y; ... }; } } here 'x' in case Point(x, y) means it's a fresh variable, if you want to use the field, you have to explicitly prefix it by 'this' (or the class for static field). If Java was not Java but Ruby (that has a different syntax for field and local variable), it may have been a good solution, but the fact that you can reference a field or a local variable using the same syntax in Java makes the option 1 not a good fit for Java. Option 2, like in Elixir, we have a special syntax to denote that a name inside a pattern is an existing local variable and not a fresh local variable. Elixir uses the operator ^ for that. var x = 0; var value = switch(shape) { case Point(^x, y) -> y; ... }; In Elixir, you declare a local variable like this "x = ..." like in Python, there is no prefix keyword let/var like in Java, JavaScript. So for Elixir, it makes sense to reuse the same syntax to create a fresh variable and to use a special syntax if you want to reference a local variable. But in Java, you declare a new local variable by prefixing it with a type or var, so using a pin operator whatever the syntax will be alien to the rest of the Java code. So Option 3, use var and the type everywhere you want to have a fresh local variable. It's stupid because in most of the cases, you want more a fresh new local variable than an existing local variable but it fits with the other constructs of the language and readability and consistence have always been more important that the number of characters in Java. I hope this help ! R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Tagir Valeev" > Cc: "amber-dev" , "Matthias Perktold" > Envoy?: Mercredi 4 Mars 2020 08:55:19 > Objet: Re: Compact deconstruction patterns > That?s all fine, but I think you are mischaracterizing the reason we are > preferring var? t?s not because we don?t like the alternative. It is because > it is the natural Combination of type inference with type patterns. And, given > that combination, there is no need to go further in the concision department, > and lots of reasons not to. > > > > Sent from my iPad > >> On Mar 4, 2020, at 5:24 AM, Tagir Valeev wrote: >> >> ?Hello! >> >>> This has come up a few times. There are several reasons to prefer the current >>> approach, most of which stem from the prime directive, ?reading code is more >>> important than writing code.? The argument for the compact version is really >>> ?I can do less typing?, which is a relatively weak motivation when the typing >>> we are saving is the three characters v-a-r. >> >> For me, this argument doesn't sound convincing. The problem is exactly >> with reading: you have to read all these noise var's, this makes lines >> longer for no big reason, your eyes need to make more horizontal >> movements. The deconstruction (especially the nested one) might >> include many fields, so it's not just four characters (var + space), >> but four times the number of pattern variables (16 in the example >> supplied by Matthias). Also, don't forget about visually impaired (not >> totally blind) people who set very big editor font having much fewer >> symbols fitting the screen horizontally. >> >> I see the arguments below, and they look more reasonable, but probably >> it's better to come with design decisions how all possible patterns >> will look like before releasing the partial feature. Probably there >> are ways to keep more common patterns shorter while allowing to write >> more complex patterns. I don't think that we should accept the var >> syntax solely because otherwise it might collide with the syntax of a >> future feature, and at the same time ask "no syntax bike shedding" for >> that future feature. What if the future feature syntax could be >> adjusted to make the clash impossible? >> >> With best regards, >> Tagir Valeev. >> >>> >>> These are variable _declarations_, and variable declarations should look like >>> declarations. `int x` and `var x` look like declarations; `x` looks like a use >>> of an existing variable. (You might point out that we do a similar thing in >>> lambdas, where we use an unadorned name, but the -> token is is a very, very >>> strong indication that these are formals. I don?t think that justification is >>> in play here. Note too that in lambdas you can say `(var x) -> ?` now, and if >>> we had `var` in the language when we did lambdas, we might well have not even >>> supported the more compact `(x,y) -> ?` form at the time. So rather than this >>> being a precedent to emulate, we might choose to view it as a historical >>> inconvenience.) >>> >>> Further, down the road, we intend to have patterns that can actually take input >>> arguments, such as `regex(?a*b*? ?)`. (Please, no syntax bike shedding on this >>> now.) This creates the possibility where the `x` in `Foo.bar(x)` could either >>> be an input parameter, or a constant pattern, or a fresh binding variable ? >>> this is asking a lot of readers. >>> >>> In the end, it comes down to: there is a benefit to being explicit (easier to >>> spot declarations), and an additional cost to being implicit (potential for >>> ambiguities down the road.) The benefit for being implicit is saving the >>> typing of three characters. This seems a pretty easy decision. >>> >>> >>>>> On Mar 3, 2020, at 9:00 AM, Matthias Perktold wrote: >>>> >>>> According to >>>> https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, the >>>> current proposal is to allow to ways of using records as deconstruction >>>> patterns: >>>> >>>> 1) With nested type patterns: case AddNode(Node left, Node right)) -> ... >>>> 2) With nested var patterns: case AddNode(var left, var right)) -> ... >>>> >>>> I was wondering whether it could make sense to allow to leave out var: >>>> case AddNode(left, right)) -> ... >>>> >>>> This would be especially convenient for nested record patterns. >>>> >>>> Compare >>>> case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... >>>> with >>>> case Line(Point(x0, y0), Point(x1, y1)) -> ... >>>> >>>> The consequence would be that the syntax rules for the innermost patterns >>>> would more closely resemble the ones for lambda parameters rather than local >>>> variables. >>>> >>>> Note that, there is no risk of ambiguity. >>>> Since it appears right after case, it's clear from the context that the >>>> whole expression is used as a pattern. >>>> The same holds for instanceof patterns. >>>> >>>> Now I'm sure this idea has already crossed your mind. >>>> Did you reject it for any particular reason? >>>> Or do you simply want to wait until you are really sure this is something >>>> you actually want? >>>> >>>> I realize this can be added any time in a future release. >>>> >>>> Thanks, >>>> Matthias >>>> From tias251 at gmail.com Wed Mar 4 11:18:42 2020 From: tias251 at gmail.com (Matthias Perktold) Date: Wed, 4 Mar 2020 12:18:42 +0100 Subject: AW: Compact deconstruction patterns In-Reply-To: <1827066791.1699559.1583317087383.JavaMail.zimbra@u-pem.fr> References: <1827066791.1699559.1583317087383.JavaMail.zimbra@u-pem.fr> Message-ID: <030801d5f216$a9e66a70$fdb33f50$@gmail.com> OK this makes sense. Now understand why my proposal is not a good idea. Thanks for taking the time to clarify things! Matthias -----Urspr?ngliche Nachricht----- Von: Remi Forax Gesendet: Mittwoch, 4. M?rz 2020 11:18 An: Matthias Perktold ; Tagir Valeev Cc: amber-dev ; Brian Goetz Betreff: Re: Compact deconstruction patterns I think Brian is miles ahead :) that's why you did not understand his answer, let me try to explain the problem and why var/type is the best choice. Let's takes an example, using the syntax you propose, var shape = ... var value = switch(shape) { case Point(x, y) -> x + y; ... }; now we also want to support adding constant as pattern, something like var value = switch(shape) { case Point(0, y) -> y; ... }; obviously, if we support constant, we also need to support variable, so the last code can be rewritten like this by introducing a new local variable x var x = 0; var value = switch(shape) { case Point(x, y) -> y; ... }; And here, i'm sure you have spot the issue, 'case Point(x, y)' is now ambiguous, because whe don't know if x refer to the local variable above or to a fresh new local variable. If you study other languages that have pattern matching, there are 3 possible solutions 1. be clever but ... 2. use a pin operator 3. use var Option 1, we can be clever, in Java, you can not introduce the same local variable twice so 'case Point(x, y)' means that x is the already existing local variable because otherwise, introducing a new fresh local variable will result in an error. But this solution has two drawbacks, the most important, it means that introducing a local variable above a switch (or an instanceof, etc) change the semantics of the switch, not a good property apart if you write code puzzler for a living. The other issue is that it interacts badly with fields. By example, if you have the code class Foo { int x; void m() { var value = switch(shape) { case Point(x, y) -> y; ... }; } } here 'x' in case Point(x, y) means it's a fresh variable, if you want to use the field, you have to explicitly prefix it by 'this' (or the class for static field). If Java was not Java but Ruby (that has a different syntax for field and local variable), it may have been a good solution, but the fact that you can reference a field or a local variable using the same syntax in Java makes the option 1 not a good fit for Java. Option 2, like in Elixir, we have a special syntax to denote that a name inside a pattern is an existing local variable and not a fresh local variable. Elixir uses the operator ^ for that. var x = 0; var value = switch(shape) { case Point(^x, y) -> y; ... }; In Elixir, you declare a local variable like this "x = ..." like in Python, there is no prefix keyword let/var like in Java, JavaScript. So for Elixir, it makes sense to reuse the same syntax to create a fresh variable and to use a special syntax if you want to reference a local variable. But in Java, you declare a new local variable by prefixing it with a type or var, so using a pin operator whatever the syntax will be alien to the rest of the Java code. So Option 3, use var and the type everywhere you want to have a fresh local variable. It's stupid because in most of the cases, you want more a fresh new local variable than an existing local variable but it fits with the other constructs of the language and readability and consistence have always been more important that the number of characters in Java. I hope this help ! R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Tagir Valeev" > Cc: "amber-dev" , "Matthias Perktold" > > Envoy?: Mercredi 4 Mars 2020 08:55:19 > Objet: Re: Compact deconstruction patterns > That?s all fine, but I think you are mischaracterizing the reason we > are preferring var? t?s not because we don?t like the alternative. It > is because it is the natural Combination of type inference with type > patterns. And, given that combination, there is no need to go further > in the concision department, and lots of reasons not to. > > > > Sent from my iPad > >> On Mar 4, 2020, at 5:24 AM, Tagir Valeev wrote: >> >> ?Hello! >> >>> This has come up a few times. There are several reasons to prefer >>> the current approach, most of which stem from the prime directive, >>> ?reading code is more important than writing code.? The argument >>> for the compact version is really ?I can do less typing?, which is a >>> relatively weak motivation when the typing we are saving is the three characters v-a-r. >> >> For me, this argument doesn't sound convincing. The problem is >> exactly with reading: you have to read all these noise var's, this >> makes lines longer for no big reason, your eyes need to make more >> horizontal movements. The deconstruction (especially the nested one) >> might include many fields, so it's not just four characters (var + >> space), but four times the number of pattern variables (16 in the >> example supplied by Matthias). Also, don't forget about visually >> impaired (not totally blind) people who set very big editor font >> having much fewer symbols fitting the screen horizontally. >> >> I see the arguments below, and they look more reasonable, but >> probably it's better to come with design decisions how all possible >> patterns will look like before releasing the partial feature. >> Probably there are ways to keep more common patterns shorter while >> allowing to write more complex patterns. I don't think that we should >> accept the var syntax solely because otherwise it might collide with >> the syntax of a future feature, and at the same time ask "no syntax >> bike shedding" for that future feature. What if the future feature >> syntax could be adjusted to make the clash impossible? >> >> With best regards, >> Tagir Valeev. >> >>> >>> These are variable _declarations_, and variable declarations should >>> look like declarations. `int x` and `var x` look like declarations; >>> `x` looks like a use of an existing variable. (You might point out >>> that we do a similar thing in lambdas, where we use an unadorned >>> name, but the -> token is is a very, very strong indication that >>> these are formals. I don?t think that justification is in play >>> here. Note too that in lambdas you can say `(var x) -> ?` now, and >>> if we had `var` in the language when we did lambdas, we might well >>> have not even supported the more compact `(x,y) -> ?` form at the >>> time. So rather than this being a precedent to emulate, we might >>> choose to view it as a historical >>> inconvenience.) >>> >>> Further, down the road, we intend to have patterns that can actually >>> take input arguments, such as `regex(?a*b*? ?)`. (Please, no syntax >>> bike shedding on this >>> now.) This creates the possibility where the `x` in `Foo.bar(x)` >>> could either be an input parameter, or a constant pattern, or a >>> fresh binding variable ? this is asking a lot of readers. >>> >>> In the end, it comes down to: there is a benefit to being explicit >>> (easier to spot declarations), and an additional cost to being >>> implicit (potential for ambiguities down the road.) The benefit for >>> being implicit is saving the typing of three characters. This seems a pretty easy decision. >>> >>> >>>>> On Mar 3, 2020, at 9:00 AM, Matthias Perktold wrote: >>>> >>>> According to >>>> https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, >>>> the current proposal is to allow to ways of using records as >>>> deconstruction >>>> patterns: >>>> >>>> 1) With nested type patterns: case AddNode(Node left, Node right)) -> ... >>>> 2) With nested var patterns: case AddNode(var left, var right)) -> ... >>>> >>>> I was wondering whether it could make sense to allow to leave out var: >>>> case AddNode(left, right)) -> ... >>>> >>>> This would be especially convenient for nested record patterns. >>>> >>>> Compare >>>> case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... >>>> with >>>> case Line(Point(x0, y0), Point(x1, y1)) -> ... >>>> >>>> The consequence would be that the syntax rules for the innermost >>>> patterns would more closely resemble the ones for lambda parameters >>>> rather than local variables. >>>> >>>> Note that, there is no risk of ambiguity. >>>> Since it appears right after case, it's clear from the context that >>>> the whole expression is used as a pattern. >>>> The same holds for instanceof patterns. >>>> >>>> Now I'm sure this idea has already crossed your mind. >>>> Did you reject it for any particular reason? >>>> Or do you simply want to wait until you are really sure this is >>>> something you actually want? >>>> >>>> I realize this can be added any time in a future release. >>>> >>>> Thanks, >>>> Matthias >>>> From amaembo at gmail.com Wed Mar 4 11:19:46 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 4 Mar 2020 18:19:46 +0700 Subject: Compact deconstruction patterns In-Reply-To: <1827066791.1699559.1583317087383.JavaMail.zimbra@u-pem.fr> References: <1827066791.1699559.1583317087383.JavaMail.zimbra@u-pem.fr> Message-ID: Hello! Yes, this clarifies things better, thanks. ??, 4 ???. 2020 ?., 18:03 Remi Forax : > I think Brian is miles ahead :) > that's why you did not understand his answer, let me try to explain the > problem and why var/type is the best choice. > > Let's takes an example, using the syntax you propose, > var shape = ... > var value = switch(shape) { > case Point(x, y) -> x + y; > ... > }; > > now we also want to support adding constant as pattern, > something like > var value = switch(shape) { > case Point(0, y) -> y; > ... > }; > > obviously, if we support constant, we also need to support variable, > so the last code can be rewritten like this by introducing a new local > variable x > var x = 0; > var value = switch(shape) { > case Point(x, y) -> y; > ... > }; > > And here, i'm sure you have spot the issue, 'case Point(x, y)' is now > ambiguous, because whe don't know if x refer to the local variable above or > to a fresh new local variable. > > If you study other languages that have pattern matching, there are 3 > possible solutions > 1. be clever but ... > 2. use a pin operator > 3. use var > > Option 1, we can be clever, in Java, you can not introduce the same local > variable twice so 'case Point(x, y)' means that x is the already existing > local variable because otherwise, introducing a new fresh local variable > will result in an error. But this solution has two drawbacks, the most > important, it means that introducing a local variable above a switch (or an > instanceof, etc) change the semantics of the switch, not a good property > apart if you write code puzzler for a living. The other issue is that it > interacts badly with fields. By example, if you have the code > class Foo { > int x; > void m() { > var value = switch(shape) { > case Point(x, y) -> y; > ... > }; > } > } > here 'x' in case Point(x, y) means it's a fresh variable, if you want to > use the field, you have to explicitly prefix it by 'this' (or the class for > static field). If Java was not Java but Ruby (that has a different syntax > for field and local variable), it may have been a good solution, but the > fact that you can reference a field or a local variable using the same > syntax in Java makes the option 1 not a good fit for Java. > > Option 2, like in Elixir, we have a special syntax to denote that a name > inside a pattern is an existing local variable and not a fresh local > variable. > Elixir uses the operator ^ for that. > var x = 0; > var value = switch(shape) { > case Point(^x, y) -> y; > ... > }; > In Elixir, you declare a local variable like this "x = ..." like in > Python, there is no prefix keyword let/var like in Java, JavaScript. So for > Elixir, it makes sense to reuse the same syntax to create a fresh variable > and to use a special syntax if you want to reference a local variable. > But in Java, you declare a new local variable by prefixing it with a type > or var, so using a pin operator whatever the syntax will be alien to the > rest of the Java code. > > So Option 3, use var and the type everywhere you want to have a fresh > local variable. It's stupid because in most of the cases, you want more a > fresh new local variable than an existing local variable but it fits with > the other constructs of the language and readability and consistence have > always been more important that the number of characters in Java. > > I hope this help ! > > R?mi > > ----- Mail original ----- > > De: "Brian Goetz" > > ?: "Tagir Valeev" > > Cc: "amber-dev" , "Matthias Perktold" < > tias251 at gmail.com> > > Envoy?: Mercredi 4 Mars 2020 08:55:19 > > Objet: Re: Compact deconstruction patterns > > > That?s all fine, but I think you are mischaracterizing the reason we are > > preferring var? t?s not because we don?t like the alternative. It is > because > > it is the natural Combination of type inference with type patterns. > And, given > > that combination, there is no need to go further in the concision > department, > > and lots of reasons not to. > > > > > > > > Sent from my iPad > > > >> On Mar 4, 2020, at 5:24 AM, Tagir Valeev wrote: > >> > >> ?Hello! > >> > >>> This has come up a few times. There are several reasons to prefer the > current > >>> approach, most of which stem from the prime directive, ?reading code > is more > >>> important than writing code.? The argument for the compact version is > really > >>> ?I can do less typing?, which is a relatively weak motivation when the > typing > >>> we are saving is the three characters v-a-r. > >> > >> For me, this argument doesn't sound convincing. The problem is exactly > >> with reading: you have to read all these noise var's, this makes lines > >> longer for no big reason, your eyes need to make more horizontal > >> movements. The deconstruction (especially the nested one) might > >> include many fields, so it's not just four characters (var + space), > >> but four times the number of pattern variables (16 in the example > >> supplied by Matthias). Also, don't forget about visually impaired (not > >> totally blind) people who set very big editor font having much fewer > >> symbols fitting the screen horizontally. > >> > >> I see the arguments below, and they look more reasonable, but probably > >> it's better to come with design decisions how all possible patterns > >> will look like before releasing the partial feature. Probably there > >> are ways to keep more common patterns shorter while allowing to write > >> more complex patterns. I don't think that we should accept the var > >> syntax solely because otherwise it might collide with the syntax of a > >> future feature, and at the same time ask "no syntax bike shedding" for > >> that future feature. What if the future feature syntax could be > >> adjusted to make the clash impossible? > >> > >> With best regards, > >> Tagir Valeev. > >> > >>> > >>> These are variable _declarations_, and variable declarations should > look like > >>> declarations. `int x` and `var x` look like declarations; `x` looks > like a use > >>> of an existing variable. (You might point out that we do a similar > thing in > >>> lambdas, where we use an unadorned name, but the -> token is is a > very, very > >>> strong indication that these are formals. I don?t think that > justification is > >>> in play here. Note too that in lambdas you can say `(var x) -> ?` > now, and if > >>> we had `var` in the language when we did lambdas, we might well have > not even > >>> supported the more compact `(x,y) -> ?` form at the time. So rather > than this > >>> being a precedent to emulate, we might choose to view it as a > historical > >>> inconvenience.) > >>> > >>> Further, down the road, we intend to have patterns that can actually > take input > >>> arguments, such as `regex(?a*b*? ?)`. (Please, no syntax bike > shedding on this > >>> now.) This creates the possibility where the `x` in `Foo.bar(x)` > could either > >>> be an input parameter, or a constant pattern, or a fresh binding > variable ? > >>> this is asking a lot of readers. > >>> > >>> In the end, it comes down to: there is a benefit to being explicit > (easier to > >>> spot declarations), and an additional cost to being implicit > (potential for > >>> ambiguities down the road.) The benefit for being implicit is saving > the > >>> typing of three characters. This seems a pretty easy decision. > >>> > >>> > >>>>> On Mar 3, 2020, at 9:00 AM, Matthias Perktold > wrote: > >>>> > >>>> According to > >>>> https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html, the > >>>> current proposal is to allow to ways of using records as > deconstruction > >>>> patterns: > >>>> > >>>> 1) With nested type patterns: case AddNode(Node left, Node right)) -> > ... > >>>> 2) With nested var patterns: case AddNode(var left, var right)) -> ... > >>>> > >>>> I was wondering whether it could make sense to allow to leave out var: > >>>> case AddNode(left, right)) -> ... > >>>> > >>>> This would be especially convenient for nested record patterns. > >>>> > >>>> Compare > >>>> case Line(Point(var x0, var y0), Point(var x1, var y1)) -> ... > >>>> with > >>>> case Line(Point(x0, y0), Point(x1, y1)) -> ... > >>>> > >>>> The consequence would be that the syntax rules for the innermost > patterns > >>>> would more closely resemble the ones for lambda parameters rather > than local > >>>> variables. > >>>> > >>>> Note that, there is no risk of ambiguity. > >>>> Since it appears right after case, it's clear from the context that > the > >>>> whole expression is used as a pattern. > >>>> The same holds for instanceof patterns. > >>>> > >>>> Now I'm sure this idea has already crossed your mind. > >>>> Did you reject it for any particular reason? > >>>> Or do you simply want to wait until you are really sure this is > something > >>>> you actually want? > >>>> > >>>> I realize this can be added any time in a future release. > >>>> > >>>> Thanks, > >>>> Matthias > >>>> > From jan.lahoda at oracle.com Wed Mar 4 11:26:45 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 04 Mar 2020 11:26:45 +0000 Subject: hg: amber/amber: 2 new changesets Message-ID: <202003041126.024BQkSr000441@aojmv0008.oracle.com> Changeset: 9ecc33cc755c Author: jlahoda Date: 2020-03-04 12:01 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/9ecc33cc755c Merging recent default branch changes into stats-before-this-super. - make/CopyInterimCLDRConverter.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore Changeset: e2821df4e6aa Author: jlahoda Date: 2020-03-04 12:25 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e2821df4e6aa Adding missing method. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java From jan.lahoda at oracle.com Wed Mar 4 16:11:40 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 04 Mar 2020 16:11:40 +0000 Subject: hg: amber/amber: 3 new changesets Message-ID: <202003041611.024GBfUd000170@aojmv0008.oracle.com> Changeset: 50425523a350 Author: jlahoda Date: 2020-03-04 16:48 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/50425523a350 Cleanup - undoing unnecessary changes ! make/CompileInterimLangtools.gmk - src/jdk.compiler/share/classes/com/sun/source/tree/AnyPatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java Changeset: 647643a62daf Author: jlahoda Date: 2020-03-04 16:54 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/647643a62daf Merging patterns-stage-2 to patterns. ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java Changeset: ace3a4b7fe8a Author: jlahoda Date: 2020-03-04 17:07 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ace3a4b7fe8a An additional fix after merge ! make/CompileInterimLangtools.gmk From alex.buckley at oracle.com Thu Mar 5 17:16:47 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Mar 2020 09:16:47 -0800 Subject: Throwing exceptions from records In-Reply-To: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> Message-ID: <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> Per JEP 359, the list for record-related discussion is amber-dev. bcc'ing jdk-dev off this thread. On 3/5/2020 9:12 AM, Ty Young wrote: > Hi, > > > Is there a way in JDK 14 records to throw exceptions from a constructor? > Currently I have dozens of classes that I want to convert to records but > am unable to due to there being no way to have a constructor that throws > exceptions. I'm not able to find any examples of how records and > exceptions are supposed to work together online either... From youngty1997 at gmail.com Thu Mar 5 19:12:43 2020 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 5 Mar 2020 13:12:43 -0600 Subject: Throwing exceptions from records In-Reply-To: <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> Message-ID: <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> Actually going to expand this a bit after messing around with records... How is records supposed to work beyond the most basic usage of Point(int x, int y)? There isn't much information out there for the more advanced usages so I'm confused. To go into more detail, I'm trying to convert this: https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java which doesn't seem possible as-is because you can't throw exceptions from record constructors. Furthermore there seems to be some constraint where constructor arguments have to match the record argument signature. Why does that even matter? As a result, I can't convert classes like: https://github.com/BlueGoliath/Crosspoint/blob/master/src/main/java/org/goliath/crosspoint/unions/BasicNativeUnion.java to a record. On 3/5/20 11:16 AM, Alex Buckley wrote: > Per JEP 359, the list for record-related discussion is amber-dev. > bcc'ing jdk-dev off this thread. > > On 3/5/2020 9:12 AM, Ty Young wrote: >> Hi, >> >> >> Is there a way in JDK 14 records to throw exceptions from a >> constructor? Currently I have dozens of classes that I want to >> convert to records but am unable to due to there being no way to have >> a constructor that throws exceptions. I'm not able to find any >> examples of how records and exceptions are supposed to work together >> online either... From vicente.romero at oracle.com Thu Mar 5 19:39:05 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Mar 2020 14:39:05 -0500 Subject: Throwing exceptions from records In-Reply-To: <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> Message-ID: Hi Ty, On 3/5/20 2:12 PM, Ty Young wrote: > > Actually going to expand this a bit after messing around with records... > > > How is records supposed to work beyond the most basic usage of > Point(int x, int y)? There isn't much information out there for the > more advanced usages so I'm confused. > > > To go into more detail, I'm trying to convert this: > > > https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java > > > > which doesn't seem possible as-is because you can't throw exceptions > from record constructors. you can't throw exceptions from _canonical_ record constructors, being a canonical record constructor the one with the same signature as the record header but you can do: record R(int i) { ??? public R() throws Exception {? // not a canonical constructor so no restriction ??????? this(someMethodReturningIntThatThrows());? // invoking the canonical constructor ??? } } > > > Furthermore there seems to be some constraint where constructor > arguments have to match the record argument signature. Why does that > even matter? only the canonical but you can declare other constructors with a different signature > > > As a result, I can't convert classes like: > > > https://github.com/BlueGoliath/Crosspoint/blob/master/src/main/java/org/goliath/crosspoint/unions/BasicNativeUnion.java > > > > to a record. HTH, Vicente > > > On 3/5/20 11:16 AM, Alex Buckley wrote: >> Per JEP 359, the list for record-related discussion is amber-dev. >> bcc'ing jdk-dev off this thread. >> >> On 3/5/2020 9:12 AM, Ty Young wrote: >>> Hi, >>> >>> >>> Is there a way in JDK 14 records to throw exceptions from a >>> constructor? Currently I have dozens of classes that I want to >>> convert to records but am unable to due to there being no way to >>> have a constructor that throws exceptions. I'm not able to find any >>> examples of how records and exceptions are supposed to work together >>> online either... From youngty1997 at gmail.com Thu Mar 5 20:04:40 2020 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 5 Mar 2020 14:04:40 -0600 Subject: Throwing exceptions from records In-Reply-To: References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> Message-ID: <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> On 3/5/20 1:39 PM, Vicente Romero wrote: > Hi Ty, > > On 3/5/20 2:12 PM, Ty Young wrote: >> >> Actually going to expand this a bit after messing around with records... >> >> >> How is records supposed to work beyond the most basic usage of >> Point(int x, int y)? There isn't much information out there for the >> more advanced usages so I'm confused. >> >> >> To go into more detail, I'm trying to convert this: >> >> >> https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java >> >> >> >> which doesn't seem possible as-is because you can't throw exceptions >> from record constructors. > > you can't throw exceptions from _canonical_ record constructors, being > a canonical record constructor the one with the same signature as the > record header but you can do: > > record R(int i) { > ??? public R() throws Exception {? // not a canonical constructor so > no restriction > ??????? this(someMethodReturningIntThatThrows());? // invoking the > canonical constructor > ??? } > } >> >> >> Furthermore there seems to be some constraint where constructor >> arguments have to match the record argument signature. Why does that >> even matter? > > only the canonical but you can declare other constructors with a > different signature The problem is that the constructor arguments require preprocessing but you can't do that since the canonical constructor has to be called first. I suppose static methods could be used to do that but that feels like a bad workaround for something that will probably be fairly common. As a knock off effect individual class implementations are basically worthless since every record that implements my "NativeFunction" interface will be forced to accept the same type arguments. That might sound like a good thing but the thing is, while they accept the same object type, the details of those objects can be very different from one another. >> >> >> As a result, I can't convert classes like: >> >> >> https://github.com/BlueGoliath/Crosspoint/blob/master/src/main/java/org/goliath/crosspoint/unions/BasicNativeUnion.java >> >> >> >> to a record. > > HTH, > > Vicente From forax at univ-mlv.fr Thu Mar 5 20:50:21 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Mar 2020 21:50:21 +0100 (CET) Subject: Throwing exceptions from records In-Reply-To: <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> Message-ID: <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Ty Young" > ?: "amber-dev" > Envoy?: Jeudi 5 Mars 2020 21:04:40 > Objet: Re: Throwing exceptions from records > On 3/5/20 1:39 PM, Vicente Romero wrote: >> Hi Ty, >> >> On 3/5/20 2:12 PM, Ty Young wrote: >>> >>> Actually going to expand this a bit after messing around with records... >>> >>> >>> How is records supposed to work beyond the most basic usage of >>> Point(int x, int y)? There isn't much information out there for the >>> more advanced usages so I'm confused. >>> >>> >>> To go into more detail, I'm trying to convert this: >>> >>> >>> https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java >>> >>> >>> >>> which doesn't seem possible as-is because you can't throw exceptions >>> from record constructors. >> >> you can't throw exceptions from _canonical_ record constructors, being >> a canonical record constructor the one with the same signature as the >> record header but you can do: >> >> record R(int i) { >> ??? public R() throws Exception {? // not a canonical constructor so >> no restriction >> ??????? this(someMethodReturningIntThatThrows());? // invoking the >> canonical constructor >> ??? } >> } >>> >>> >>> Furthermore there seems to be some constraint where constructor >>> arguments have to match the record argument signature. Why does that >>> even matter? >> >> only the canonical but you can declare other constructors with a >> different signature > > > The problem is that the constructor arguments require preprocessing but > you can't do that since the canonical constructor has to be called > first. I suppose static methods could be used to do that but that feels > like a bad workaround for something that will probably be fairly common. It's common to avoid to throw checked exceptions in constructor because instead of first creating the object (with new) and then throwing the exception, it's better to throw the exception before the creation of the object. The usual alternatives are as you said either use a static method which is very common when dealing with IOException or use an unchecked exception instead. and as a meta comment, debugging constructors is hard because you are at the point where every objects is mutable, it's a good idea to only have initialization code in a constructor (this.foo = foo) or preconditions (Objects.reuireNonNull(...)), so to have a code is so simple that you will never have a bug in a constructor. If you follow that rule, i promise you will never be angry anymore :) regards, R?mi From vicente.romero at oracle.com Thu Mar 5 21:53:54 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 05 Mar 2020 21:53:54 +0000 Subject: hg: amber/amber: initial push records-2 branch Message-ID: <202003052153.025Lrswc023955@aojmv0008.oracle.com> Changeset: 61aebf6881a2 Author: vromero Date: 2020-03-05 16:53 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/61aebf6881a2 initial push records-2 branch From vicente.romero at oracle.com Thu Mar 5 22:01:16 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Mar 2020 17:01:16 -0500 Subject: new amber repo for records, the sequel Message-ID: Hi, I have created a new repo at amber named records-2 to speed up the development of new record features that are still being discussed, specified, etc., aiming at 15+. Bug fixes of existing features will still happen at the jdk repo. Thanks, Vicente From maurizio.cimadamore at oracle.com Thu Mar 5 22:05:15 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:05:15 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052205.025M5FR3029291@aojmv0008.oracle.com> Changeset: 02cdaf34af06 Author: mcimadamore Date: 2020-03-05 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/02cdaf34af06 Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:05:42 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:05:42 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052205.025M5gig029605@aojmv0008.oracle.com> Changeset: 80f6919b6aff Author: mcimadamore Date: 2020-03-05 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/80f6919b6aff Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:06:27 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:06:27 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052206.025M6Re1001280@aojmv0008.oracle.com> Changeset: ae64327b1910 Author: mcimadamore Date: 2020-03-05 22:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/ae64327b1910 Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:08:32 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:08:32 +0000 Subject: hg: amber/amber: Automatic merge with pattern-runtime Message-ID: <202003052208.025M8WUo005608@aojmv0008.oracle.com> Changeset: 9f06f1a957c0 Author: mcimadamore Date: 2020-03-05 22:08 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/9f06f1a957c0 Automatic merge with pattern-runtime - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh ! test/langtools/TEST.ROOT - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:08:52 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:08:52 +0000 Subject: hg: amber/amber: Automatic merge with patterns-stage-2 Message-ID: <202003052208.025M8qTw006029@aojmv0008.oracle.com> Changeset: 7b82b68fc3a4 Author: mcimadamore Date: 2020-03-05 22:08 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/7b82b68fc3a4 Automatic merge with patterns-stage-2 ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:01:14 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:01:14 +0000 Subject: hg: amber/amber: 223 new changesets Message-ID: <202003052201.025M1RWI027969@aojmv0008.oracle.com> Changeset: 7e6165c9c606 Author: naoto Date: 2020-02-13 17:14 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/7e6165c9c606 8239017: cmp-baseline fails because of differences in TimeZoneNames_kea Reviewed-by: erikj ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java Changeset: f425abab6723 Author: bulasevich Date: 2020-02-14 10:03 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/f425abab6723 8238643: ARM32 build fails after JDK-8230199 Reviewed-by: shade, lfoltan ! src/hotspot/cpu/arm/interpreterRT_arm.cpp Changeset: f82f59ef79f0 Author: bulasevich Date: 2020-02-14 10:05 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/f82f59ef79f0 8231118: ARM32: Math tests failures Reviewed-by: roland ! src/hotspot/cpu/arm/assembler_arm_32.hpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp Changeset: ddae16cc505c Author: jjiang Date: 2020-02-14 16:53 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ddae16cc505c 8239025: ProblemList java/net/httpclient/HandshakeFailureTest.java due to JDK-8238990 Reviewed-by: chegar ! test/jdk/ProblemList.txt Changeset: 2852b64d04ae Author: redestad Date: 2020-02-14 10:16 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/2852b64d04ae 8238863: Refactor out static initialization from Dict constructors Reviewed-by: neliasso, dlong ! src/hotspot/share/libadt/dict.cpp Changeset: 78e17b715fae Author: neliasso Date: 2020-02-12 20:53 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/78e17b715fae 8203883: Remove State from InvocationCounters Reviewed-by: redestad, thartmann ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/tieredThresholdPolicy.cpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/invocationCounter.cpp ! src/hotspot/share/interpreter/invocationCounter.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/whitebox.cpp Changeset: 8d03748fae04 Author: roland Date: 2020-01-13 10:00 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8d03748fae04 8236759: ShouldNotReachHere in PhaseIdealLoop::verify_strip_mined_scheduling Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/loopstripmining/LoadSplitThruPhi.java Changeset: 374452022582 Author: dnsimon Date: 2020-02-14 09:25 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/374452022582 8238758: [JVMCI] fix JVMCI jtreg events tests to work with GraalVM Reviewed-by: kvn, dlong, never ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java Changeset: 9b4d873446c9 Author: cjplummer Date: 2020-02-14 10:28 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/9b4d873446c9 8238196: tests that use SA Attach should not be allowed to run against signed binaries on Mac OS X 10.14.5 and later Reviewed-by: sspitsyn, iignatyev ! test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java ! test/hotspot/jtreg/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java ! test/lib/jdk/test/lib/Platform.java Changeset: af8e77a59bd8 Author: darcy Date: 2020-02-14 12:47 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/af8e77a59bd8 8239092: Provide explicit specification for getKind methods of javax.lang.model Reviewed-by: jjg, prappo ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java Changeset: 1c6c48d3136b Author: egahlin Date: 2020-02-14 23:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1c6c48d3136b 8238959: Add missing classpath exception to FileAcess and ConstantLookup Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantLookup.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/FileAccess.java Changeset: 81ef9be35699 Author: weijun Date: 2020-02-15 09:26 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/81ef9be35699 8160818: GssKrb5Client violates RFC 4752 Reviewed-by: xuelei ! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java + test/jdk/sun/security/krb5/auto/SaslMutual.java Changeset: 274a0bcce99d Author: jiefu Date: 2020-02-15 17:35 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/274a0bcce99d 8239110: Zero VM build fails after JDK-8203883 Reviewed-by: aph ! src/hotspot/share/interpreter/invocationCounter.cpp Changeset: 6f40f03179f9 Author: rschuenemann Date: 2020-02-13 10:07 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6f40f03179f9 8238534: Deep sign macOS bundles before bundle archive is being created Reviewed-by: erikj, clanger ! make/Bundles.gmk ! make/autoconf/spec.gmk.in Changeset: f3f66f9e98ee Author: ysuenaga Date: 2020-02-17 11:12 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/f3f66f9e98ee 8237818: Typo in Unsafe: resposibility Reviewed-by: ysuenaga Contributed-by: Aya Ebata ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Changeset: 690fc7e5a90f Author: ihse Date: 2020-02-17 08:59 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/690fc7e5a90f 8213185: Properly handle run-test-prebuilt -> test-prebuilt migration Reviewed-by: erikj + make/Global.gmk - make/Help.gmk ! make/Init.gmk ! make/RunTestsPrebuilt.gmk ! make/conf/jib-profiles.js Changeset: 26136b5b27bf Author: stefank Date: 2020-02-17 10:03 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/26136b5b27bf 8183574: Unify the is_power_of_2 functions Reviewed-by: kbarrett, redestad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/interp_masm_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/assembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp ! src/hotspot/cpu/s390/interp_masm_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp ! src/hotspot/cpu/sparc/c1_LIRGenerator_sparc.cpp ! src/hotspot/cpu/sparc/interp_masm_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/adlc/main.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciArray.cpp ! src/hotspot/share/code/codeHeapState.cpp ! src/hotspot/share/code/vtableStubs.cpp ! src/hotspot/share/gc/g1/g1BiasedArray.hpp ! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/z/zAddress.inline.hpp ! src/hotspot/share/gc/z/zLiveMap.cpp ! src/hotspot/share/gc/z/zMarkCache.cpp ! src/hotspot/share/gc/z/zMarkStack.cpp ! src/hotspot/share/gc/z/zNMethodTable.cpp ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/memory/heap.cpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/divnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp ! src/hotspot/share/utilities/align.hpp ! src/hotspot/share/utilities/globalDefinitions.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/powerOfTwo.hpp ! test/hotspot/gtest/gc/z/test_zForwarding.cpp ! test/hotspot/gtest/utilities/test_powerOfTwo.cpp Changeset: efc0da4a10a9 Author: roland Date: 2020-02-14 10:31 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/efc0da4a10a9 8238691: C2: turn subtype check into macro node Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/classes.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/phase.hpp ! src/hotspot/share/opto/subnode.cpp + src/hotspot/share/opto/subtypenode.cpp + src/hotspot/share/opto/subtypenode.hpp Changeset: f53f0d0637d8 Author: rrich Date: 2020-02-13 16:20 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f53f0d0637d8 8239005: [TESTBUG] test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPages.java: exeinvoke.c: must initialize static state before calling do_overflow() Reviewed-by: dholmes, clanger ! test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c Changeset: 9513c13b03f3 Author: rkennke Date: 2020-02-14 19:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/9513c13b03f3 8239081: Shenandoah: Consolidate C1 LRB and native barriers Reviewed-by: shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp Changeset: 27e87c000b16 Author: mbaesken Date: 2020-02-13 11:11 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/27e87c000b16 8239000: handle ContendedPaddingWidth in vm_version_ppc Reviewed-by: clanger, lucy ! src/hotspot/cpu/ppc/vm_version_ppc.cpp Changeset: b4a8d0c9da88 Author: chagedorn Date: 2020-02-17 12:29 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/b4a8d0c9da88 8238765: PhaseCFG::schedule_pinned_nodes cannot handle precedence edges from unmatched CFG nodes correctly Summary: Fix PhaseCFG::schedule_pinned_nodes to correctly handle precedence edges from unmatched CFG nodes. Reviewed-by: roland, neliasso, kvn ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/gcm.cpp Changeset: 6308389bdc83 Author: chagedorn Date: 2020-02-17 12:29 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6308389bdc83 8239069: C2: SIGSEGV in IdealGraphPrinter::walk_nodes due to C->root() being NULL Summary: Fix NULL pointer dereference when trying to print the ideal graph when Compile::record_failure() is called twice. Reviewed-by: neliasso, thartmann ! src/hotspot/share/opto/idealGraphPrinter.cpp Changeset: 140261de4a17 Author: egahlin Date: 2020-02-17 22:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/140261de4a17 8238236: Add JFR class redefinition events Reviewed-by: mgronlun ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.hpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/jdk/test/lib/jfr/Events.java ! test/lib/jdk/test/lib/util/JavaAgentBuilder.java Changeset: 220415dfb4ac Author: igerasim Date: 2020-02-17 16:32 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/220415dfb4ac 8163251: Hard coded loop limit prevents reading of smart card data greater than 8k Reviewed-by: valeriep, rriggs ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java Changeset: 40ce3b9a71eb Author: xuelei Date: 2020-02-17 18:52 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/40ce3b9a71eb 8239264: Clearup the legacy ObjectIdentifier constructor from int array Reviewed-by: jnimeh ! src/java.base/macosx/classes/apple/security/KeychainStore.java ! src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/java.base/share/classes/java/security/cert/X509CertSelector.java ! src/java.base/share/classes/sun/security/pkcs/ContentInfo.java ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/java.base/share/classes/sun/security/util/ObjectIdentifier.java ! src/java.base/share/classes/sun/security/x509/AccessDescription.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/classes/sun/security/x509/ExtendedKeyUsageExtension.java ! src/java.base/share/classes/sun/security/x509/GeneralSubtrees.java ! src/java.base/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java ! src/java.base/share/classes/sun/security/x509/NetscapeCertTypeExtension.java ! src/java.base/share/classes/sun/security/x509/OIDMap.java ! src/java.base/share/classes/sun/security/x509/PKIXExtensions.java ! src/java.base/share/classes/sun/security/x509/X500Name.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/XECParameters.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java ! test/jdk/sun/security/util/Oid/OidEquals.java ! test/jdk/sun/security/util/Oid/OidFormat.java ! test/jdk/sun/security/x509/AVA/AVAEqualsHashCode.java ! test/jdk/sun/security/x509/X509CertImpl/V3Certificate.java Changeset: 83949f956490 Author: thartmann Date: 2020-02-18 08:28 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/83949f956490 8239142: C2's UseUniqueSubclasses optimization is broken for array accesses Summary: Avoid resetting the elemtype for array accesses. Reviewed-by: vlivanov, eosterlund ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse2.cpp Changeset: 8124177833ec Author: pconcannon Date: 2020-02-18 09:42 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/8124177833ec 8237480: Add micros for DatagramSocket send/receive Summary: Benchmarks for the DatagramSocket::send and DatagramSocket::receive methods Reviewed-by: chegar, dfuchs, redestad + test/micro/org/openjdk/bench/java/net/DatagramSocketSendReceive.java Changeset: 26cdbd64d461 Author: tschatzl Date: 2020-02-18 10:59 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/26cdbd64d461 8238999: Remove MemRegion custom new/delete operator overloads Reviewed-by: kbarrett, jiangli, iklam ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/memRegion.cpp ! src/hotspot/share/memory/memRegion.hpp Changeset: 7d73b376f5d2 Author: iwalulya Date: 2020-02-18 11:00 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/7d73b376f5d2 8232686: Turn parallel gc develop tracing flags into unified logging Reviewed-by: sjohanss, tschatzl, lkorinth ! src/hotspot/share/gc/parallel/parallel_globals.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: a502b482d5c3 Author: egahlin Date: 2020-02-18 14:34 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a502b482d5c3 8239265: JFR: Test cleanup of jdk.jfr.api.consumer package Reviewed-by: mgronlun ! test/jdk/jdk/jfr/api/consumer/TestFieldAccess.java ! test/jdk/jdk/jfr/api/consumer/TestGetStackTrace.java ! test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java ! test/jdk/jdk/jfr/api/consumer/TestMethodGetModifiers.java ! test/jdk/jdk/jfr/api/consumer/TestReadTwice.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedClassLoader.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedEvent.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedEventGetThread.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedEventGetThreadOther.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedInstantEventTimestamp.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedMethodDescriptor.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedObject.java ! test/jdk/jdk/jfr/api/consumer/TestRecordingFile.java ! test/jdk/jdk/jfr/api/consumer/TestRecordingFileReadEventEof.java ! test/jdk/jdk/jfr/api/consumer/TestSingleRecordedEvent.java ! test/jdk/jdk/jfr/api/consumer/TestValueDescriptorRecorded.java Changeset: 615b494384e4 Author: egahlin Date: 2020-02-18 16:34 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/615b494384e4 8239350: Add tests for JFR class redefinition events Reviewed-by: mgronlun + test/jdk/jdk/jfr/event/runtime/Bytes.java + test/jdk/jdk/jfr/event/runtime/RedefinableClass.java + test/jdk/jdk/jfr/event/runtime/TestClassRedefinition.java + test/jdk/jdk/jfr/event/runtime/TestRedefineClasses.java + test/jdk/jdk/jfr/event/runtime/TestRetransformClasses.java Changeset: d1c0dc3719c6 Author: mbaesken Date: 2020-02-18 16:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d1c0dc3719c6 8239224: libproc_impl.c previous_thr may be used uninitialized warning Reviewed-by: clanger, dholmes ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c Changeset: de9088d16202 Author: rkennke Date: 2020-02-18 17:20 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/de9088d16202 8237780: Shenandoah: More reliable nmethod verification Reviewed-by: shade, zgu ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: 328ba6a75f41 Author: mseledtsov Date: 2020-02-18 08:14 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/328ba6a75f41 8167493: Test that JFR event can be retransformed by an agent Summary: Added new test, extended agent builder test library Reviewed-by: egahlin + test/jdk/jdk/jfr/javaagent/InstrumentationEventCallback.java + test/jdk/jdk/jfr/javaagent/TestEventInstrumentation.java ! test/lib/jdk/test/lib/util/JavaAgentBuilder.java Changeset: af8b73f2a13d Author: hseigel Date: 2020-02-18 16:30 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/af8b73f2a13d 8187305: Add logging for shared library loads/unloads Summary: Add logging to JVM_LoadLibrary(), JVM_UnloadLibrary(), and JVM_FindLibraryEntry(). Reviewed-by: dholmes, coleenp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/prims/jvm.cpp + test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java + test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibraryTest.java + test/hotspot/jtreg/runtime/logging/loadLibraryTest/libLoadLibraryClass.c Changeset: 925e981292b2 Author: lmesnik Date: 2020-02-18 10:48 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/925e981292b2 8239026: Support non-maven artifacts by JibArtifactManager Reviewed-by: erikj ! test/lib/jdk/test/lib/artifacts/DefaultArtifactManager.java ! test/lib/jdk/test/lib/artifacts/JibArtifactManager.java Changeset: bab64f4a1f24 Author: erikj Date: 2020-02-18 11:21 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/bab64f4a1f24 8239019: testmake fails with FATAL: VCS_TYPE is empty Reviewed-by: rriggs ! bin/idea.sh Changeset: a614219d7388 Author: egahlin Date: 2020-02-18 22:25 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a614219d7388 8210977: jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject Reviewed-by: mgronlun, mseledtsov ! test/jdk/jdk/jfr/event/oldobject/TestThreadLocalLeak.java Changeset: ed7f82f396e1 Author: jjg Date: 2020-02-18 14:08 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ed7f82f396e1 8239378: Add Classpath Exception to license in source file. Reviewed-by: vromero ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/external-link.svg Changeset: a38520aac11f Author: prappo Date: 2020-02-18 23:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/a38520aac11f 8238969: Miscellaneous cleanup Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTaskImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TableHeader.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/DocletElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/OverviewElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/IllegalOptionValue.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Main.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: 21ed4ee81974 Author: rhalade Date: 2020-02-18 16:00 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/21ed4ee81974 8225128: Add exception for expiring DocuSign root to VerifyCACerts test Reviewed-by: clanger ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 46bb1175b837 Author: darcy Date: 2020-02-18 17:03 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/46bb1175b837 8237450: JDK13 annotation processors not run when a supported annotation type specifies a module Summary: Initial fix suggested by jjg based on through analysis by Jeremy Kuhn. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/langtools/tools/javac/diags/examples/RedundantTypesWithWildcardProc/processors/AnnoProc.java Changeset: 8307dcef629a Author: mbaesken Date: 2020-02-18 10:28 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8307dcef629a 8239333: test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails intermittent Reviewed-by: clanger ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java Changeset: ed8eb5e3e385 Author: mbaesken Date: 2020-02-18 16:46 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ed8eb5e3e385 8238953: tools/jpackage tests do not work on Ubuntu Linux Reviewed-by: asemenyuk, clanger ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java Changeset: ba5e9182b08c Author: mdoerr Date: 2020-02-19 09:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ba5e9182b08c 8239363: PPC64: Wrong code generation after JDK-8183574 Reviewed-by: stuefe, stefank, lucy ! src/hotspot/cpu/ppc/assembler_ppc.cpp Changeset: b0417eb55b11 Author: tschatzl Date: 2020-02-19 10:04 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/b0417eb55b11 8239070: Memory leak when unsuccessfully mapping in archive regions Reviewed-by: kbarrett, iklam, coleenp, jiangli ! src/hotspot/share/memory/filemap.cpp Changeset: de0fa05b18c7 Author: glaubitz Date: 2020-02-19 10:10 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/de0fa05b18c7 8239001: Hotspot build broken on linux-sparc after 8238281 Reviewed-by: dholmes, kbarrett ! src/hotspot/cpu/sparc/macroAssembler_sparc.hpp Changeset: dbe22aa857d9 Author: rraghavan Date: 2020-02-19 15:01 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/dbe22aa857d9 8238356: CodeHeap::blob_count() overestimates the number of blobs Summary: Decremented _blob_count on addition to the free list Reviewed-by: lucy, shade, thartmann ! src/hotspot/share/memory/heap.cpp Changeset: 80e403e1ff94 Author: prappo Date: 2020-02-19 10:34 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/80e403e1ff94 8239243: Create index structures only if required Reviewed-by: hannesw, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java Changeset: 96d78010ed9f Author: michaelm Date: 2020-02-19 11:31 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/96d78010ed9f 8239139: test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c does not compile with gcc 8.3.1 Reviewed-by: michaelm Contributed-by: linzang at tencent.com ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c Changeset: 81133b1ca410 Author: fparain Date: 2020-02-19 08:57 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/81133b1ca410 8239014: -XX:-UseEmptySlotsInSupers sometime fails to reproduce the layout of the old code Reviewed-by: dholmes, coleenp ! src/hotspot/share/classfile/fieldLayoutBuilder.cpp ! src/hotspot/share/classfile/fieldLayoutBuilder.hpp + test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java Changeset: ad9525a5d546 Author: sgehwolf Date: 2019-12-16 15:07 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ad9525a5d546 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy Reviewed-by: bobv, mchung + src/java.base/linux/classes/jdk/internal/platform/CgroupInfo.java + src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java + src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystem.java + src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java + src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java + src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java + src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java + src/java.base/linux/classes/jdk/internal/platform/CgroupV1MetricsImpl.java + src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1MemorySubSystemController.java + src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java + src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java + src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java + src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java ! test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java + test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemController.java ! test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/CPUSetsReader.java + test/lib/jdk/test/lib/containers/cgroup/CgroupMetricsTester.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java + test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java + test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java Changeset: b2dd4028a6de Author: darcy Date: 2020-02-19 11:52 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/b2dd4028a6de 8239478: Make specification of SourceVersion.isName explicit for dotted names Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Changeset: 0bd237b74e70 Author: jnimeh Date: 2020-02-19 13:36 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/0bd237b74e70 8239094: PKCS#9 ChallengePassword attribute does not allow for the UTF8String type Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java + test/jdk/sun/security/pkcs/pkcs9/ChallengePassStringFmt.java Changeset: 3150e6810c21 Author: jwilhelm Date: 2020-02-20 03:11 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/3150e6810c21 Added tag jdk-15+11 for changeset b2dd4028a6de ! .hgtags Changeset: 2489925df497 Author: mbaesken Date: 2020-02-19 10:27 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/2489925df497 8239351: Give more meaningful InternalError messages in Deflater.c Reviewed-by: stuefe, vtewari, lancea, martin ! src/java.base/share/native/libzip/Deflater.c Changeset: 8432f7d4f51c Author: ihse Date: 2020-02-20 10:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8432f7d4f51c 8239450: Overhaul JVM feature handling in configure Reviewed-by: erikj ! doc/building.html ! doc/building.md ! make/autoconf/basics.m4 ! make/autoconf/configure.ac ! make/autoconf/help.m4 ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 + make/autoconf/jvm-features.m4 ! make/conf/jib-profiles.js ! src/hotspot/.mx.jvmci/mx_jvmci.py Changeset: 9b999cf5e13a Author: clanger Date: 2020-02-07 08:38 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/9b999cf5e13a 8237192: Generate stripped/public pdbs on Windows for jdk images Reviewed-by: erikj, ihse Contributed-by: christoph.langer at sap.com, matthias.baesken at sap.com ! make/Bundles.gmk ! make/CreateJmods.gmk ! make/GenerateLinkOptData.gmk ! make/Images.gmk ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/common/NativeCompilation.gmk ! make/launcher/Launcher-java.base.gmk ! make/scripts/compare.sh ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/jdk/tools/launcher/TestHelper.java ! test/jdk/tools/launcher/VersionCheck.java Changeset: d23e418e91fe Author: redestad Date: 2020-02-20 13:18 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d23e418e91fe 8239347: Refactor Symbol to make _length a standalone field again Reviewed-by: iklam, coleenp ! make/hotspot/src/native/dtrace/generateJvmOffsets.cpp ! src/hotspot/os/solaris/dtrace/jhelper.d ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/solaris/native/libjvm_db/libjvm_db.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Symbol.java Changeset: 461e0b7e6dfe Author: coleenp Date: 2020-02-20 07:25 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/461e0b7e6dfe 8239461: Use jcod rather than jar files in runtime tests Reviewed-by: hseigel, lmesnik, dholmes - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar ! test/hotspot/jtreg/runtime/EnclosingMethodAttr/EnclMethodAttr.java - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod + test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.jcod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod + test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.jcod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod + test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.jcod ! test/hotspot/jtreg/runtime/LocalVariableTable/TestLVT.java - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar + test/hotspot/jtreg/runtime/VerifierMessages/Test7116786.java + test/hotspot/jtreg/runtime/VerifierMessages/testcases.jcod ! test/hotspot/jtreg/runtime/classFileParserBug/ClassFileParserBug.java ! test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar ! test/hotspot/jtreg/runtime/duplAttributes/DuplAttributesTest.java - test/hotspot/jtreg/runtime/duplAttributes/test.jar Changeset: 60a77203ac91 Author: rriggs Date: 2020-02-20 10:03 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/60a77203ac91 8232622: Technical debt in BadAttributeValueExpException Reviewed-by: dfuchs, sspitsyn ! src/java.management/share/classes/javax/management/BadAttributeValueExpException.java Changeset: eae299d8ada4 Author: iveresov Date: 2020-02-20 10:11 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/eae299d8ada4 8238355: Update Graal Reviewed-by: kvn ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CodeSectionProcessor.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ForeignGotCallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/amd64/AMD64ELFMacroAssembler.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/FileSupport.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives/src/org/graalvm/compiler/api/directives/GraalDirectives.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitution.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64AddressingModeTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64InstructionEncodingTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MoveConstantTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/TestProtectedAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64MacroAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64Address.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64BaseAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64MacroAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AVXKind.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.code/src/org/graalvm/compiler/code/CompilationResult.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.code/src/org/graalvm/compiler/code/HexCodeFile.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64ArrayAddressTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64BitwiseLogicalNotTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64ElideL2ITest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64FloatSqrtTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64MembarOpTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64MergeNarrowWithExtendTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64RotationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64AddressLoweringByUse.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64PointerAddNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64ReadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64SuitesCreator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64.test/src/org/graalvm/compiler/core/amd64/test/AMD64MatchRuleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64AddressLowering.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64AddressNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64LIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64NodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64SuitesCreator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/Fields.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/GraalOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/NumUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/AbstractControlFlowGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/IntegerStamp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.match.processor/src/org/graalvm/compiler/core/match/processor/MatchProcessor.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCIntegerCompareCanonicalizationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCNodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/BoxingEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CheckGraalInvariants.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationMulTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CountedLoopTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/DeMorganCanonicalizationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/DegeneratedLoopsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraalCompilerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/HashMapGetTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/IntegerDivRemCanonicalizationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InterfaceMethodHandleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InvokeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InvokeHintsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LongNodeChainTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MarkUnsafeAccessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MatchRuleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MemoryGraphCanonicalizeTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MonitorGraphTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/OffHeapUnsafeAccessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ReferenceGetLoopTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SubprocessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnsafeVirtualizationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifySystemPropertyUsage.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/deopt/RethrowExceptionLoopTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EarlyReadEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PEAAssertionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PEAReadEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeAnalysisIterationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeAnalysisTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeAnalysisTreesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeUnsafeStoreTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/TrufflePEATest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/UnsafeEATest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/InliningTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalCompiler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/DebugInfoBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeLIRBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/BaseTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/HighTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/MidTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugConfigImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugContext.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MethodFilter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/ScopeImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/doc-files/MethodFilterHelp.txt ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Graph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeClass.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotDeoptimizeCallerOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotDeoptimizeOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotDeoptimizeWithExceptionCallerOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotEpilogueOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64IndirectCallOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64DeoptimizeOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotAddressLowering.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotConstantRetrievalOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotDeoptimizeWithExceptionCallerOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotReturnOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotUnwindOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotspotDirectVirtualCallOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64IndirectCallOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCDeoptimizeOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotDeoptimizeCallerOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotDeoptimizeWithExceptionCallerOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompileTheWorld.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompileTheWorldTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotDeoptExplicitExceptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotDeoptPostExceptions.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/LambdaStableNameTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/MethodSubstitutionEffectTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/NodeCostDumpUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/TestSHASubstitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/WriteBarrierAdditionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfigVersioned.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotCompiledCodeBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotDebugInfoBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalCompilerFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalManagementRegistration.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntimeProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotReferenceMapBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/SymbolicSnippetEncoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotNodePlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotObjdumpDisassemblerProvider.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotPlatformConfigurationProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotProviders.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotSuitesProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotWordOperationPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/BeginLockScopeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DeoptimizeWithExceptionInCallerNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/EndLockScopeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/StubForeignCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/InitializeKlassNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/InitializeKlassStubCall.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/ResolveDynamicConstantNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/ResolveDynamicStubCall.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/FastNotifyNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotAllocationSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotG1WriteBarrierSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotspotSnippetsOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/IdentityHashCodeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/MonitorSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ObjectCloneNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/UnsafeCopyMemoryNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/UnsafeLoadSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/CreateExceptionStub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/Stub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/word/MetaspacePointer.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/word/PointerCastNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParserOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/DefaultSuitesCreator.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/LambdaUtils.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/backend/LargeConstantSectionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/except/UntrustedInterfaces.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/ConditionalElimination02.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/Narrow_byte04.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/TrichotomyTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/reflect/Field_set02.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ArithmeticOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64BitManipulationOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Move.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Arithmetic.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayCompareToOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayEqualsOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayIndexOfOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64CCall.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Call.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ControlFlow.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathCosOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathExpOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathLog10Op.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathLogOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathPowOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathSinOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathTanOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Move.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64StringLatin1InflateOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64StringUTF16CompressOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/vector/AMD64VectorUnary.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.sparc/src/org/graalvm/compiler/lir/sparc/SPARCControlFlow.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRInstruction.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRIntrospection.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/lsra/LinearScan.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/asm/CompilationResultBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/constopt/ConstantLoadOptimization.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/dfa/MarkBasePointersPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/dfa/RegStackValueSet.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/phases/EconomyAllocationStage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/util/IndexedValueMap.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopPeelingPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopTransformations.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.test/src/org/graalvm/compiler/loop/test/LoopPartialUnrollTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/CountedLoopInfo.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/DefaultLoopPolicies.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopFragmentInside.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopPolicies.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/MathUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/GraalBenchmark.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMHWhitebox.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/AbstractBeginNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GuardProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GuardedValueNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/Invoke.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeWithExceptionNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/KillingBeginNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/LoopBeginNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StartNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StructuredGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ValueNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ValueProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/CompareNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/FloatEqualsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/LeftShiftNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NarrowNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/OrNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/SignExtendNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/SignedRemNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/ZeroExtendNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/cfg/Block.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/SideEffectNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/StringToBytesNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/BytecodeExceptionNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/ForeignCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/JavaReadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/JavaWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/MembarNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/MonitorExit.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/RawLoadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/RawStoreNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/UnsafeAccessNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/UnsafeMemoryStoreNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/gc/BarrierSet.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/gc/CardTableBarrierSet.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/gc/G1BarrierSet.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/LoopExplosionPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AbstractCompareAndSwapNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AbstractUnsafeCompareAndSwapNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AccessMonitorNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AtomicReadAndAddNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AtomicReadAndWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/ExceptionObjectNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/LoadIndexedNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/LogicCompareAndSwapNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/LoweredAtomicReadAndWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MonitorEnterNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MonitorExitNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/RawMonitorEnterNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/ValueCompareAndSwapNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/AbstractMemoryCheckpoint.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/AbstractWriteNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/AddressableMemoryAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FixedAccessNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FloatingAccessNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FloatingReadNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/GuardedMemoryAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/LIRLowerableAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryKill.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryPhiNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MultiMemoryKill.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/OnHeapMemoryAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/ReadNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/SingleMemoryKill.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/VolatileReadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/WriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/CoreProviders.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/CoreProvidersDelegate.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/CoreProvidersImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/PlatformConfigurationProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/VirtualizerTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/virtual/AllocatedObjectNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/virtual/CommitAllocationNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/virtual/VirtualArrayNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/virtual/VirtualObjectNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionKey.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/AddressLoweringByUsePhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/FloatingReadPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/InsertGuardFencesPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/LoweringPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ProfileCompiledMethodsPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/WriteBarrierAdditionPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/info/MultiTypeGuardInlineInfo.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/BasePhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/contract/NodeCostUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/SchedulePhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/ScheduleVerification.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/util/Providers.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/CFGPrinterObserver.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/GraalDebugHandlersFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64BitCountNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64CountLeadingZerosNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64CountTrailingZerosNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringLatin1InflateNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringUTF16CompressNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.jdk9.test/src/org/graalvm/compiler/replacements/jdk9/test/VarHandleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.sparc/src/org/graalvm/compiler/replacements/sparc/SPARCGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ArrayStoreBytecodeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/BitOpNodesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/BytecodeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ClassCastBytecodeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/EdgesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/IndexOobBytecodeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/NullBytecodeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ObjectAccessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/PEGraphDecoderTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/PointerTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/AllocationSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DimensionsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/NodeIntrinsificationProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/PEGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetTemplate.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/CheckcastArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/GenericArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/gc/G1WriteBarrierSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayEqualsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayRegionEqualsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BasicArrayCopyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BasicObjectCloneNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BitCountNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/MacroStateSplitNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/GraalTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/EarlyReadEliminationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/ObjectState.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PEReadEliminationClosure.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PartialEscapeClosure.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PartialEscapePhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/ReadEliminationBlockState.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/ReadEliminationClosure.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/VirtualizerToolImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/Word.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/WordOperationPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.graphio/src/org/graalvm/graphio/DefaultGraphTypes.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.micro.benchmarks/src/micro/benchmarks/GroupAllocationBenchmark.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.micro.benchmarks/src/micro/benchmarks/ObjectCloneArrayLengthBenchmark.java Changeset: 38fc3785784a Author: dfuchs Date: 2020-02-20 20:04 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/38fc3785784a 8238990: java/net/httpclient/HandshakeFailureTest.java failed against TLSv1.3 on Windows Summary: The SSLTube and SSLFlowDelegate are improved to wrap any non-SSL exception that occur during the handshake in an SSLHandshakeException. Reviewed-by: chegar ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLTube.java ! test/jdk/ProblemList.txt ! test/jdk/java/net/httpclient/HandshakeFailureTest.java Changeset: e3bc1e0ec534 Author: mullan Date: 2020-02-20 16:36 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/e3bc1e0ec534 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property Reviewed-by: xuelei ! src/java.base/share/conf/security/java.security + test/jdk/sun/security/ssl/CipherSuite/LegacyConstraints.java Changeset: 9c05db2c5715 Author: pliden Date: 2020-02-20 23:07 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/9c05db2c5715 8239503: FieldLayout/OldLayoutCheck.java fails due to "RuntimeException: Misplaced int field: expected 24 to equal 12" Summary: Don't run the test with ZGC. Reviewed-by: dcubed, coleenp, dholmes ! test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java Changeset: 18cc3b9dcebf Author: ihse Date: 2020-02-21 10:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/18cc3b9dcebf 8239566: gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory" Reviewed-by: redestad ! make/autoconf/hotspot.m4 ! make/autoconf/libraries.m4 Changeset: 67268dd9d46a Author: mbaesken Date: 2020-02-20 11:09 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/67268dd9d46a 8239537: cgroup MetricsTester testMemorySubsystem fails sometimes when testing memory.kmem.tcp.usage_in_bytes Reviewed-by: mseledtsov ! test/lib/jdk/test/lib/containers/cgroup/CgroupMetricsTester.java Changeset: 1958182c5315 Author: mbaesken Date: 2020-02-20 14:01 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1958182c5315 8238947: tools/jpackage tests fail with old rpmbuild versions Reviewed-by: clanger, asemenyuk ! src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/LinuxRpmBundler.java Changeset: 43e03e193ed8 Author: iwalulya Date: 2020-02-21 10:56 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/43e03e193ed8 8216975: Using ForceNUMA does not disable adaptive sizing with parallel gc Reviewed-by: kbarrett, tschatzl, lkorinth ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/solaris/os_solaris.cpp Changeset: b1471b50e56c Author: aoqi Date: 2020-02-19 12:09 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/b1471b50e56c 8239422: [TESTBUG] compiler/c1/TestPrintIRDuringConstruction.java failed when C1 is disabled Summary: Skip test if C1 is not available. Reviewed-by: thartmann, xliu ! test/hotspot/jtreg/compiler/c1/TestPrintIRDuringConstruction.java Changeset: b0299f002b6a Author: aoqi Date: 2020-02-19 12:10 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/b0299f002b6a 8239424: [TESTBUG] compiler/whitebox/OSRFailureLevel4Test.java failed when TieredCompilation is disabled Summary: Skip test if TieredCompilation is not available. Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/whitebox/OSRFailureLevel4Test.java Changeset: 1bf02ccb788f Author: lucy Date: 2020-02-21 15:14 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1bf02ccb788f 8239456: vtable stub generation: assert failure (code size estimate) Reviewed-by: thartmann ! src/hotspot/cpu/x86/vtableStubs_x86_32.cpp ! src/hotspot/cpu/x86/vtableStubs_x86_64.cpp Changeset: c22b369d40b2 Author: clanger Date: 2020-02-21 16:39 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/c22b369d40b2 8239556: (zipfs) remove ExistingChannelCloser facility in zipfs implementation Reviewed-by: lancea ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Changeset: ef47c784e37b Author: ihse Date: 2020-02-21 18:37 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ef47c784e37b 8239708: Split basics.m4 into basic.m4 and util.m4 Reviewed-by: erikj + make/autoconf/basic.m4 + make/autoconf/basic_tools.m4 + make/autoconf/basic_windows.m4 - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 ! make/autoconf/boot-jdk.m4 ! make/autoconf/build-performance.m4 ! make/autoconf/configure.ac ! make/autoconf/flags.m4 ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/jvm-features.m4 ! make/autoconf/lib-tests.m4 ! make/autoconf/libraries.m4 ! make/autoconf/source-dirs.m4 ! make/autoconf/toolchain.m4 ! make/autoconf/toolchain_windows.m4 + make/autoconf/util.m4 + make/autoconf/util_paths.m4 + make/autoconf/util_windows.m4 Changeset: 6759c7955b3b Author: mseledtsov Date: 2020-02-21 13:01 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/6759c7955b3b 8223217: [TESTBUG] Create JFR tests with JMX across container boundary Summary: Created a new test for JFR over JMX across container boundary Reviewed-by: egahlin, lmesnik + test/hotspot/jtreg/containers/docker/EventProducer.java + test/hotspot/jtreg/containers/docker/TestJFRWithJMX.java Changeset: 321b6fbe6815 Author: weijun Date: 2020-02-22 08:10 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/321b6fbe6815 8237218: Support NIST Curves verification in java implementation Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/util/ECUtil.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java + test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: 23363df27cb6 Author: dholmes Date: 2020-02-23 22:35 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/23363df27cb6 8238988: Rename thread "in stack" methods and add in_stack_range Reviewed-by: coleenp, dcubed ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/sparc/frame_sparc.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/solaris/os_solaris.cpp ! src/hotspot/os/solaris/os_solaris.hpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp ! src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.cpp ! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp ! src/hotspot/os_cpu/solaris_x86/thread_solaris_x86.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/unhandledOops.cpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 8b79fb59978e Author: mbaesken Date: 2020-02-19 13:37 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8b79fb59978e 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Reviewed-by: alanb, clanger ! src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c Changeset: 13dc2a7f74aa Author: redestad Date: 2020-02-24 10:20 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/13dc2a7f74aa 8239235: Examine SignatureStream performance after consolidation Reviewed-by: lfoltan, coleenp ! src/hotspot/share/classfile/stackMapFrame.cpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/verifier.hpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp + test/hotspot/gtest/runtime/test_signatureStream.cpp Changeset: 5c5dcd036a76 Author: pliden Date: 2020-02-24 11:01 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/5c5dcd036a76 8239533: ZGC: Make the ZProactive flag non-diagnostic Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/z_globals.hpp ! test/hotspot/jtreg/gc/z/TestHighUsage.java Changeset: 1db771b65440 Author: neliasso Date: 2020-02-24 11:31 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1db771b65440 8238723: yank_alloc_node must remove membar Reviewed-by: vlivanov, thartmann, roland ! src/hotspot/share/opto/macro.cpp ! test/hotspot/jtreg/compiler/allocation/TestAllocation.java Changeset: 19c8bc956f73 Author: rrich Date: 2020-02-24 12:04 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/19c8bc956f73 8239854: Non-PCH gtest build fails after JDK-8239235 due to a missing include Reviewed-by: shade, mdoerr ! test/hotspot/gtest/runtime/test_signatureStream.cpp Changeset: 38319837aeec Author: jlahoda Date: 2020-02-24 11:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/38319837aeec 8239536: Can't use `java.util.List` object after importing `java.awt.List` Summary: Using full qualified names for synthetic types; ensuring the user is warned when a variable becomes undefined due to a dependency change. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: d6dd48a23a72 Author: pliden Date: 2020-02-24 13:52 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d6dd48a23a72 8239129: ZGC: Allow -XX:AllocateHeapAt to use any filesystem Reviewed-by: stefank, pliden, ysuenaga Contributed-by: yasuenag at gmail.com, per.liden at oracle.com ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp + test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java Changeset: af80fedc56a2 Author: rrich Date: 2020-02-24 14:25 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/af80fedc56a2 8239449: [TESTBUG] test/hotspot/jtreg/runtime/TLS/TestTLS.java: skip test if glibc too old for AdjustStackSizeForTLS Reviewed-by: dholmes, jiangli ! test/hotspot/jtreg/runtime/TLS/exestack-tls.c Changeset: ef1e608a5ecc Author: egahlin Date: 2020-02-24 15:03 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ef1e608a5ecc 8239581: Improve javadoc example for @jdk.jfr.Category Reviewed-by: mgronlun, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/Category.java Changeset: fe2befa06c39 Author: eosterlund Date: 2020-02-24 14:37 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/fe2befa06c39 8234160: Enable optimized mitigation for Intel jcc erratum in C2 Reviewed-by: thartmann, vlivanov, pliden + src/hotspot/cpu/x86/c2_intelJccErratum_x86.cpp + src/hotspot/cpu/x86/c2_intelJccErratum_x86.hpp ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/output.cpp Changeset: d3b8307bd677 Author: hannesw Date: 2020-02-24 16:42 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d3b8307bd677 8232438: Remove ?is-external=true from external links Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocLink.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPath.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java ! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/langtools/jdk/javadoc/doclet/testDocRootInlineTag/TestDocRootInlineTag.java ! test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithAutomaticModule.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithModule.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java Changeset: 207fa617f855 Author: egahlin Date: 2020-02-24 17:10 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/207fa617f855 8239585: JFR: Native events should support empty payloads Reviewed-by: mgronlun ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java ! src/hotspot/share/jfr/metadata/metadata.xsd Changeset: 9374fc702a03 Author: egahlin Date: 2020-02-24 17:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/9374fc702a03 8239793: 'jfr' tool should hide hidden frames Reviewed-by: mgronlun, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java Changeset: 2dcefc0b8a6d Author: dfuchs Date: 2020-02-24 17:19 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/2dcefc0b8a6d 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3 Summary: The test assumed that ByteBuffer would be split at long boundaries. This is obviously not always the case. A carry has been added to support reading a long split over several buffers. Reviewed-by: chegar ! test/jdk/java/net/httpclient/HandshakeFailureTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/AbstractSSLTubeTest.java Changeset: 582928e18beb Author: shade Date: 2020-02-24 18:30 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/582928e18beb 8239868: Shenandoah: ditch C2 node limit adjustments Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: d33754052039 Author: shade Date: 2020-02-24 18:30 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d33754052039 8239492: [x86] Turn MacroAssembler::verify_oop into macro recording file and line Reviewed-by: rrich, vlivanov, pliden ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/share/gc/z/zVerify.cpp Changeset: d8c731f7aeda Author: iignatyev Date: 2020-02-24 11:50 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/d8c731f7aeda 8238943: switch to jtreg 5.0 Reviewed-by: erikj, jjg, joehw ! make/conf/jib-profiles.js ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/langtools/TEST.ROOT ! test/nashorn/TEST.ROOT Changeset: 4202cb763872 Author: naoto Date: 2020-02-24 12:20 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/4202cb763872 8239837: Typo in source code of ZoneOffsetTransitionRule leaking to Javadocs Reviewed-by: lancea ! src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java Changeset: be0c5da2d83f Author: naoto Date: 2020-02-24 14:16 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/be0c5da2d83f 8239520: ValueRange.of(long, long, long) does not throw IAE on invalid inputs Reviewed-by: rriggs ! src/java.base/share/classes/java/time/temporal/ValueRange.java ! test/jdk/java/time/test/java/time/temporal/TestDateTimeValueRange.java Changeset: 6214823ce3d8 Author: ddong Date: 2020-02-24 23:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6214823ce3d8 8237499: JFR: Include stack trace in the ThreadStart event Reviewed-by: egahlin ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/support/jfrThreadLocal.cpp ! src/hotspot/share/jfr/support/jfrThreadLocal.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc ! test/jdk/jdk/jfr/event/runtime/TestThreadStartEndEvents.java Changeset: f965bceba123 Author: cito Date: 2020-02-25 03:28 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f965bceba123 8219904: ClassCastException when calling FlightRecorderMXBean#getRecordings() Reviewed-by: egahlin, mseledtsov ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RecordingInfo.java ! test/jdk/jdk/jfr/jmx/JmxHelper.java ! test/jdk/jdk/jfr/jmx/TestGetRecordings.java Changeset: 1c7da538f065 Author: jiefu Date: 2020-02-25 10:34 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/1c7da538f065 8239886: Minimal VM build fails after JDK-8237499 Reviewed-by: dholmes ! src/hotspot/share/prims/jni.cpp Changeset: d6b968af8b65 Author: fmatte Date: 2020-02-24 23:44 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/d6b968af8b65 8239557: [TESTBUG] VeryEarlyAssertTest.java validating "END." marker at lastline is not always true Reviewed-by: dholmes, mseledtsov ! test/hotspot/jtreg/runtime/ErrorHandling/VeryEarlyAssertTest.java Changeset: 22422bef1c5d Author: jiefu Date: 2020-02-25 16:22 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/22422bef1c5d 8239885: [TESTBUG] compiler/allocation/TestAllocation.java fails with release VMs Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/allocation/TestAllocation.java Changeset: 874f29bf3f44 Author: ihse Date: 2020-02-25 09:37 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/874f29bf3f44 8239860: Add support for testing the configure script Reviewed-by: erikj ! make/RunTests.gmk ! make/autoconf/util.m4 ! test/make/TestMake.gmk + test/make/autoconf/test-configure.sh + test/make/autoconf/test.m4 Changeset: d2cd0d717997 Author: ihse Date: 2020-02-25 09:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d2cd0d717997 8239789: Follow-up on JVM feature rewrite Reviewed-by: erikj, pliden, egahlin ! make/autoconf/help.m4 ! make/autoconf/jvm-features.m4 ! make/autoconf/util.m4 Changeset: 4f902f017def Author: ihse Date: 2020-02-25 09:46 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4f902f017def 8239794: Move -Os from JVM feature 'minimal' to new feature 'opt-size' Reviewed-by: erikj, dholmes ! make/autoconf/jvm-features.m4 ! make/hotspot/lib/JvmFeatures.gmk Changeset: 695c6b0986c3 Author: shade Date: 2020-02-25 12:35 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/695c6b0986c3 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Changeset: 9b33b25a7198 Author: itakiguchi Date: 2020-02-25 22:47 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/9b33b25a7198 8235834: IBM-943 charset encoder needs updating Summary: Apply 34B003AF.RPMAP130 definition into encoder Reviewed-by: naoto + make/data/charsetmapping/IBM943.c2b ! test/jdk/sun/nio/cs/TestIBMBugs.java Changeset: 9e359ab51ce6 Author: sgehwolf Date: 2020-02-20 20:56 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/9e359ab51ce6 8239559: Cgroups: Incorrect detection logic on some systems Summary: Adjust heuristic with cgroup mounts according to mountinfo Reviewed-by: bobv, mbaesken ! src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java + test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java Changeset: a268c653f404 Author: egahlin Date: 2020-02-25 20:45 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a268c653f404 8223066: "jfr metadata" output the @Name annotation twice Reviewed-by: mgronlun, egahlin Contributed-by: erik.gahlin at oracle.com, chiroito107 at gmail.com ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java ! test/jdk/jdk/jfr/tool/TestMetadata.java Changeset: 16973c5b27be Author: naoto Date: 2020-02-25 15:49 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/16973c5b27be 8239976: Put JDK-8239965 on the ProblemList.txt Reviewed-by: dcubed ! test/jdk/ProblemList.txt Changeset: ff1f4b5e0c9a Author: pli Date: 2020-02-26 09:33 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ff1f4b5e0c9a 8239549: AArch64: Backend support for MulAddVS2VI node Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! test/hotspot/jtreg/compiler/loopopts/superword/Vec_MulAddS2I.java Changeset: cf96533fd215 Author: darcy Date: 2020-02-25 17:50 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/cf96533fd215 8193553: Provide better guidance on using javax.lang.model visitors Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/element/AnnotationValueVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/type/TypeVisitor.java Changeset: a8bca51623b6 Author: ngasson Date: 2020-02-26 09:58 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/a8bca51623b6 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable with Xcomp on AArch64 Reviewed-by: mseledtsov, egahlin ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceG1GCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceParallelGCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java Changeset: afeefc19ecb9 Author: aoqi Date: 2020-02-26 00:07 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/afeefc19ecb9 8239423: jdk/jfr/jvm/TestJFRIntrinsic.java failed with -XX:-TieredCompilation Reviewed-by: iignatyev, dholmes ! src/hotspot/share/prims/whitebox.cpp Changeset: 61ee15b9a1ac Author: mbaesken Date: 2020-02-24 09:59 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/61ee15b9a1ac 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns Reviewed-by: clanger, amenkov, sspitsyn ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp ! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m ! src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp Changeset: 582e5f2661c3 Author: xliu Date: 2020-02-26 12:35 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/582e5f2661c3 8239066: make LinkedList more generic Reviewed-by: phh, simonis ! src/hotspot/share/utilities/linkedlist.hpp ! test/hotspot/gtest/utilities/test_linkedlist.cpp Changeset: c27d95f72ba8 Author: coffeys Date: 2020-02-26 18:06 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/c27d95f72ba8 8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 Reviewed-by: pkoppula, weijun, coffeys Contributed-by: ravi.k.reddy at oracle.com ! src/java.base/share/classes/sun/security/x509/CertificateValidity.java ! src/java.base/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java + test/jdk/sun/security/x509/X509CertImpl/CertificateValidation.java Changeset: 230455dd03c1 Author: prappo Date: 2020-02-26 15:34 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/230455dd03c1 8239876: Improve SearchIndexItem Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItem.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItems.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java Changeset: 0c158c2a2385 Author: iignatyev Date: 2020-02-26 10:09 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/0c158c2a2385 8239500: jittester shouldn't use non-deterministic System methods Reviewed-by: lmesnik, thartmann ! test/hotspot/jtreg/testlibrary/jittester/conf/exclude.methods.lst Changeset: 495566ff7149 Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/495566ff7149 8240069: Shenandoah: turn more flags diagnostic Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestCodeCacheRootStyles.java Changeset: a1be565c0afe Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a1be565c0afe 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java Changeset: 525cbaab106d Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/525cbaab106d 8240076: Shenandoah: pacer should cover reset and preclean phases Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp Changeset: 2ec0ff304263 Author: kbarrett Date: 2020-02-26 14:36 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/2ec0ff304263 8238979: Improve G1DirtyCardQueueSet handling of previously paused buffers Summary: Move enqueuing of previously paused buffers. Reviewed-by: sangheki, sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: f67951f722a4 Author: redestad Date: 2020-02-26 21:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f67951f722a4 8240094: Optimize empty substring handling Reviewed-by: redestad, igerasim, jlaskey Contributed-by: sergei.tsypanov at yandex.ru ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java ! test/micro/org/openjdk/bench/java/lang/StringSubstring.java Changeset: 541b03673cdb Author: dcubed Date: 2020-02-26 19:33 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/541b03673cdb 8240132: ProblemList com/sun/jdi/InvokeHangTest.java Reviewed-by: mikael ! test/jdk/ProblemList.txt Changeset: bccb9f3423e3 Author: dcubed Date: 2020-02-26 19:39 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/bccb9f3423e3 8240134: ProblemList javax/script/Test7.java Reviewed-by: dholmes ! test/jdk/ProblemList.txt Changeset: 57849c7f9d22 Author: dcubed Date: 2020-02-26 19:41 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/57849c7f9d22 8240135: ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 Reviewed-by: iignatyev, dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: 95c882e86df2 Author: jwilhelm Date: 2020-02-27 03:10 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/95c882e86df2 Added tag jdk-15+12 for changeset 2ec0ff304263 ! .hgtags Changeset: 76f3aaaffd3c Author: dholmes Date: 2020-02-26 23:10 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/76f3aaaffd3c 8240141: Incorrect copyright header in src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp Reviewed-by: iignatyev ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp Changeset: 3b9b5cb7586f Author: amlu Date: 2020-02-27 12:19 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/3b9b5cb7586f 8239979: sun/security/tools/keytool/ExtOptionCamelCase.java is not run Reviewed-by: rhalade ! test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java Changeset: 495d1a4eee04 Author: rraghavan Date: 2020-02-27 16:06 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/495d1a4eee04 8235995: Remove src/jdk.internal.vm.compiler/.mx.graal directory Summary: Removed src/jdk.internal.vm.compiler/.mx.graal directory and files Reviewed-by: dlong - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py Changeset: c87cb2daad04 Author: neliasso Date: 2020-02-27 13:11 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c87cb2daad04 8239878: Bug in PrintEliminateAllocations code causes TestClhsdbJstackLock.java to fail Reviewed-by: shade ! src/hotspot/share/opto/macro.cpp Changeset: e6336e3c5984 Author: hseigel Date: 2020-02-27 13:00 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/e6336e3c5984 8235225: Replace CHECK_0 with CHECK_NULL for non-integer returning methods Summary: Change CHECK_0 to CHECK_NULL and CHECK_false where appropriate Reviewed-by: mikael, dholmes, coleenp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classListParser.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/services/management.cpp ! src/hotspot/share/services/memoryManager.cpp Changeset: b5745158500a Author: zgu Date: 2020-02-26 15:32 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/b5745158500a 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahForwarding.hpp ! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp Changeset: 0b02c862a03e Author: dcubed Date: 2020-02-27 11:34 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/0b02c862a03e 8239873: [TESTBUG] FieldLayout/OldLayoutCheck.java fails after the fix for JDK-8239503 Summary: Don't run the test with -XX:-UseCompressedOops. Reviewed-by: fparain, hseigel ! test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java Changeset: 8f26915495d6 Author: zgu Date: 2020-02-27 12:17 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/8f26915495d6 8239354: Shenandoah: minor enhancements to traversal GC Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 7abee91f0bb5 Author: darcy Date: 2020-02-27 10:30 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/7abee91f0bb5 8225495: Note whether returned annotations are declaration annotations or type annotations Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 6e9aa02cf215 Author: wetmore Date: 2020-02-27 11:48 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/6e9aa02cf215 8239815: Update ECC legal file Reviewed-by: mullan ! src/jdk.crypto.ec/share/legal/ecc.md Changeset: 52367bbd4bd4 Author: jjg Date: 2020-02-27 12:16 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/52367bbd4bd4 8239804: Cleanup/simplify HTML/CSS for general block tags Reviewed-by: prappo, hannesw ! make/jdk/src/classes/build/tools/taglet/ModuleGraph.java ! make/jdk/src/classes/build/tools/taglet/ToolGuide.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ParamTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! test/langtools/jdk/javadoc/doclet/AuthorDD/AuthorDD.java ! test/langtools/jdk/javadoc/doclet/testAuthor/TestAuthor.java ! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/langtools/jdk/javadoc/doclet/testConstructorIndent/TestConstructorIndent.java ! test/langtools/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/langtools/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java + test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverriddenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/langtools/jdk/javadoc/doclet/testHiddenMembers/TestHiddenMembers.java ! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlStrongTag/TestHtmlStrongTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestMultiInheritance.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenMethodDocCopy.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPackageFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPrivateFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg1/BaseClass.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg1/SubClass.java ! test/langtools/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/pkg/PrivateParent.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/pkg/PublicChild.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/langtools/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/langtools/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java ! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java ! test/langtools/jdk/javadoc/doclet/testThrowsHead/TestThrowsHead.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/langtools/jdk/javadoc/doclet/testVersionTag/TestVersionTag.java Changeset: a30f7d67296e Author: cjplummer Date: 2020-02-27 13:51 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/a30f7d67296e 8240142: Fix copyright in ThreadGroupReferenceImpl.h Reviewed-by: dholmes ! src/jdk.jdwp.agent/share/native/libjdwp/ThreadGroupReferenceImpl.h Changeset: 7e846d63ca61 Author: cjplummer Date: 2020-02-27 13:52 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/7e846d63ca61 8239379: ProblemList serviceability/sa/sadebugd/DebugdConnectTest.java on OSX Reviewed-by: sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 04ba72c457f3 Author: cjplummer Date: 2020-02-27 13:57 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/04ba72c457f3 8193237: SA: ClhsdbLauncher should show the command being executed Reviewed-by: sspitsyn, amenkov ! test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Changeset: 02f6ce8441df Author: xuelei Date: 2020-02-27 21:14 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/02f6ce8441df 8240193: loadLibrary("osxsecurity") should not be removed Reviewed-by: ascarpino ! src/java.base/macosx/classes/apple/security/KeychainStore.java Changeset: 27e301f90b3a Author: ihse Date: 2020-02-28 09:53 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/27e301f90b3a 8239799: Cross-compilation ARM32/AARCH clientvm builds fails after JDK-8239450 Reviewed-by: erikj ! make/autoconf/buildjdk-spec.gmk.in Changeset: 8def7c4e6800 Author: chagedorn Date: 2020-02-28 15:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8def7c4e6800 8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed Summary: Remove an assertion which was too strong for some valid IRs when running with -XX:+VerifyGraphEdges Reviewed-by: neliasso, thartmann ! src/hotspot/share/opto/gcm.cpp Changeset: 1a57db1b936f Author: dcubed Date: 2020-02-28 10:16 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/1a57db1b936f 8240231: Build failure on illumos after 8238988 Summary: add missing cast Reviewed-by: dcubed, shade Contributed-by: peter.tribble at gmail.com ! src/hotspot/os_cpu/solaris_x86/thread_solaris_x86.cpp Changeset: ec5e6e8d1ed2 Author: lucy Date: 2020-02-28 16:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ec5e6e8d1ed2 8239931: [win][x86] vtable stub generation: assert failure (code size estimate) follow-up Reviewed-by: mdoerr ! src/hotspot/cpu/x86/vtableStubs_x86_32.cpp Changeset: c838a35b86e9 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c838a35b86e9 8240215: Shenandoah: remove ShenandoahAllocationTrace Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: df9f37c56847 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/df9f37c56847 8240216: Shenandoah: remove ShenandoahTerminationTrace Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: c005ba590219 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c005ba590219 8240217: Shenandoah: remove ShenandoahEvacAssist Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: d1062bce95b9 Author: simonis Date: 2020-02-28 19:49 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d1062bce95b9 8240226: DeflateIn_InflateOut.java test incorrectly assumes size of compressed file Reviewed-by: martin, alanb ! test/jdk/java/util/zip/DeflateIn_InflateOut.java Changeset: 9d59ab73463c Author: jjg Date: 2020-02-28 12:46 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/9d59ab73463c 8240136: Cleanup/simplify HTML/CSS for definition lists Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java + test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/TestExternalOverriddenMethod.java + test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/package-list + test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/pkg/XReader.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverriddenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testPackageHtml/TestPackageHtml.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java Changeset: 7b59e4c72006 Author: lmesnik Date: 2020-02-28 13:21 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/7b59e4c72006 8203239: [TESTBUG] remove vmTestbase/vm/gc/kind/parOld test Reviewed-by: lkorinth, shade ! test/hotspot/jtreg/TEST.quick-groups - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh Changeset: f227e770495f Author: minqi Date: 2020-02-28 15:30 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/f227e770495f 8236604: Optimize SystemDictionary::resolve_well_known_classes for CDS Summary: Serialize SystemDictionary::_well_known_classes into CDS and quickly resolve them at runtime in vm startup stage. Reviewed-by: iklam, coleenp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp Changeset: 0569a84a9ec0 Author: jiefu Date: 2020-02-29 09:38 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/0569a84a9ec0 8240254: Build is broken when cds is disabled after JDK-8236604 Reviewed-by: redestad ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: f46dfe6b18ac Author: minqi Date: 2020-02-28 19:29 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/f46dfe6b18ac 8240258: SystemDictionary::quick_resolve need guarded by INCLUDE_CDS Summary: Supplemental fix for 8236604 to guard SystemDictionary::quick_resolve with CDS Reviewed-by: iklam, ccheung ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: eeba18e49d0b Author: lzang Date: 2020-02-29 14:43 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/eeba18e49d0b 8239916: SA: delete dead code in jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Reviewed-by: stefank ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Changeset: 1e4e7bf0b6f5 Author: fyang Date: 2020-02-26 17:32 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/1e4e7bf0b6f5 8239915: Zero VM crashes when handling dynamic constant Reviewed-by: dholmes Contributed-by: wangkun49 at huawei.com ! src/hotspot/share/interpreter/bytecodeInterpreter.cpp + test/hotspot/jtreg/runtime/invokedynamic/DynamicConstantHelper.jasm + test/hotspot/jtreg/runtime/invokedynamic/TestDynamicConstant.java Changeset: 4a5a7dc9d05c Author: iklam Date: 2020-03-01 17:36 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/4a5a7dc9d05c 8240267: VM fails to start with CDS enabled but JVMTI disabled Reviewed-by: dholmes ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp Changeset: 4b9d816b1531 Author: rhalade Date: 2020-03-01 23:04 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/4b9d816b1531 8225130: Add exception for expiring Comodo roots to VerifyCACerts test Reviewed-by: weijun ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: acc083236275 Author: redestad Date: 2020-03-02 08:22 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/acc083236275 8196334: Optimize UUID#fromString Reviewed-by: igerasim, alanb Contributed-by: plokhotnyuk at gmail.com, jon.chambers at gmail.com, claes.redestad at oracle.com ! src/java.base/share/classes/java/util/UUID.java ! test/jdk/java/util/UUID/UUIDTest.java + test/micro/org/openjdk/bench/java/util/UUIDBench.java Changeset: 1d64bd5b34e0 Author: chagedorn Date: 2020-03-02 10:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1d64bd5b34e0 8238438: SuperWord::co_locate_pack picks memory state of first instead of last load Summary: Fix selection of first and last memory state in SuperWord::co_locate_pack Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp + test/hotspot/jtreg/compiler/loopopts/superword/CoLocatePackMemoryState.java Changeset: 41073408f25e Author: stefank Date: 2020-03-02 12:30 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/41073408f25e 8240220: IdealLoopTree::dump_head predicate printing is broken Reviewed-by: thartmann, neliasso, chagedorn ! src/hotspot/share/opto/loopnode.cpp Changeset: e04746cec89c Author: stefank Date: 2020-03-02 12:30 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e04746cec89c 8240223: Use consistent predicate order in and with PhaseIdealLoop::find_predicate Reviewed-by: thartmann, neliasso, chagedorn ! src/hotspot/share/opto/loopUnswitch.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 387369ff21a4 Author: mbalao Date: 2020-02-05 12:20 -0300 URL: https://hg.openjdk.java.net/amber/amber/rev/387369ff21a4 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB Reviewed-by: mullan, valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java Changeset: 5f6949a3dbe0 Author: hseigel Date: 2020-03-02 16:10 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/5f6949a3dbe0 8239568: [TESTBUG] LoadLibraryTest.java fails with RuntimeException Summary: Throw jtreg.SkippedException instead of failing if shared library isn't unloaded Reviewed-by: coleenp, lmesnik - test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java ! test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibraryTest.java ! test/hotspot/jtreg/runtime/logging/loadLibraryTest/libLoadLibraryClass.c Changeset: e826821a469d Author: pconcannon Date: 2020-03-02 16:47 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/e826821a469d 8234812: Add micros for DatagramChannel send/receive Summary: Benchmarks for the DatagramChannel::send and DatagramChannel::receive methods Reviewed-by: alanb, chegar + test/micro/org/openjdk/bench/java/nio/DatagramChannelSendReceive.java Changeset: 3a9bd48ecffc Author: lfoltan Date: 2020-03-02 18:42 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/3a9bd48ecffc 8237766: Enhance signature API to include ResolvingSignatureStream Summary: New ResolvingSignatureStream class provides the capability to easily walk through the differing parts of a signature while resolving or querying its underlying types. Reviewed-by: coleenp, fparain, hseigel Contributed-by: lois.foltan at oracle.com, john.r.rose at oracle.com ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp Changeset: ac3371755ede Author: kbarrett Date: 2020-03-02 14:45 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/ac3371755ede 8240246: Avoid cast_to_oop from char* Summary: Change type of gtest object from char[] to unsigned char[]. Reviewed-by: dholmes ! test/hotspot/gtest/oops/test_oop.cpp Changeset: 83ff8e2fa7ab Author: mseledtsov Date: 2020-03-02 12:16 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/83ff8e2fa7ab 8236938: [TESTBUG] JFR event MetaspaceAllocationFailure is not tested Summary: New test for MetaspaceAllocationFailure Reviewed-by: hseigel, stuefe ! test/hotspot/jtreg/runtime/Metaspace/FragmentMetaspace.java - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java + test/jdk/jdk/jfr/event/runtime/TestMetaspaceAllocationFailure.java + test/lib/jdk/test/lib/classloader/GeneratingCompilingClassLoader.java Changeset: 80e4a066342d Author: dholmes Date: 2020-03-02 19:49 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/80e4a066342d 8238676: jni crashes on accessing it from process exit hook Reviewed-by: fparain, gziemski ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/prims/jni.cpp + test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java + test/hotspot/jtreg/runtime/jni/atExit/libatExit.c Changeset: f3d90cac1c7c Author: prr Date: 2020-02-12 14:45 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/f3d90cac1c7c 8238842: AIOOBE in GIFImageReader.initializeStringTable Reviewed-by: serb, bpb ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java + test/jdk/javax/imageio/plugins/gif/GIFCodeSizeTest.java Changeset: 314f940aaf82 Author: serb Date: 2020-02-13 13:17 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/314f940aaf82 8238738: AudioSystem.getMixerInfo() takes about 30 sec to report a gone audio device Reviewed-by: prr ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp Changeset: 19adbbca4307 Author: serb Date: 2020-02-13 13:19 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/19adbbca4307 8221823: Requested JDialog width is ignored Reviewed-by: aivanov ! src/java.desktop/windows/classes/sun/awt/windows/WDialogPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WFramePeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java ! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java ! test/jdk/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java ! test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java + test/jdk/java/awt/Window/MinimumSizeDPIVariation/MinimumSizeDPIVariation.java Changeset: bdcad73943d5 Author: serb Date: 2020-02-13 13:21 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/bdcad73943d5 8238741: java.awt.Robot(GraphicsDevice) constructor does not follow the spec Reviewed-by: aivanov ! src/java.desktop/share/classes/java/awt/Robot.java + test/jdk/java/awt/Headless/HeadlessRobot.java Changeset: ece447fa3843 Author: serb Date: 2020-02-13 13:23 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ece447fa3843 8233827: Enable screenshots in the enhanced failure handler on Linux/macOS Reviewed-by: iignatyev ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties Changeset: df45736e03ac Author: prr Date: 2020-02-14 09:10 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/df45736e03ac 8238942: Rendering artifacts with LCD text and fractional metrics Reviewed-by: serb, jdv ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: bc9c585b41e7 Author: prr Date: 2020-02-14 10:44 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/bc9c585b41e7 8239091: Reversed arguments in call to strstr in freetype "debug" code. Reviewed-by: bpb ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: 81bb0384f515 Author: kizune Date: 2020-02-17 20:04 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/81bb0384f515 8237221: [macos] java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java fails Reviewed-by: serb + test/jdk/java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java Changeset: 062b36ecf8d7 Author: psadhukhan Date: 2020-02-20 14:49 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/062b36ecf8d7 8239334: Tab Size does not work correctly in JTextArea with setLineWrap on Reviewed-by: serb, pbansal ! src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java + test/jdk/javax/swing/JTextArea/TestTabSizeWithLineWrap.java Changeset: c28ebdb28a8e Author: pbansal Date: 2020-02-21 16:31 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/c28ebdb28a8e 8216329: Cannot resize CheckBoxItemMenu in Synth L&F with setHorizontalTextPosition Reviewed-by: serb, psadhukhan ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java + test/jdk/javax/swing/plaf/synth/SynthCheckBoxMenuItem/Check_Icon.png + test/jdk/javax/swing/plaf/synth/SynthCheckBoxMenuItem/MenuItem_Selected.png + test/jdk/javax/swing/plaf/synth/SynthCheckBoxMenuItem/TestJCheckBoxMenuItem.java Changeset: 427e3df3f0a3 Author: pbansal Date: 2020-02-21 17:00 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/427e3df3f0a3 8153090: TAB key cannot change input focus after the radio button in the Color Selection dialog Reviewed-by: serb, psadhukhan ! src/java.desktop/share/classes/javax/swing/colorchooser/ColorPanel.java Changeset: 159f96d0784c Author: pbansal Date: 2020-02-21 17:09 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/159f96d0784c 8238985: [TESTBUG] The arrow image is blue instead of green Reviewed-by: serb, psadhukhan ! test/jdk/javax/swing/JTextPane/TestJTextPaneHTMLRendering.java Changeset: ea4c6da34c1f Author: aivanov Date: 2020-02-25 20:00 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/ea4c6da34c1f 8235147: Release HDC from passiveDCList sooner Reviewed-by: serb, jdv ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Component.h Changeset: 965c0a1421e5 Author: serb Date: 2020-02-27 09:49 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/965c0a1421e5 8239583: [AIX] simplify the native references in X input methods Reviewed-by: clanger, itakiguchi ! src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c ! src/java.desktop/unix/native/common/awt/awt_p.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c Changeset: 69495f2ee5ba Author: serb Date: 2020-02-28 16:49 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/69495f2ee5ba 8240202: A few client tests leave mouse buttons pressed Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java ! test/jdk/javax/swing/JButton/PressedButtonRightClickTest.java Changeset: ed5224c3e044 Author: psadhukhan Date: 2020-03-02 10:50 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/ed5224c3e044 Merge - make/CopyInterimCLDRConverter.gmk - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh ! test/jdk/ProblemList.txt - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java Changeset: d765d242df98 Author: psadhukhan Date: 2020-03-03 13:31 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/d765d242df98 Merge - test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java Changeset: 370822016750 Author: neliasso Date: 2020-03-03 10:29 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/370822016750 8238759: Clones should always keep the base pointer Reviewed-by: rkennke, thartmann ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! test/hotspot/jtreg/compiler/arguments/TestStressReflectiveCode.java Changeset: 1bc5f223df65 Author: simonis Date: 2020-03-03 11:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1bc5f223df65 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly Reviewed-by: martin, clanger, lancea ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: de17bc931bbe Author: redestad Date: 2020-03-03 11:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/de17bc931bbe 8240302: x64: Assembler::reachable redundantly call Relocation::type() more than once Reviewed-by: kvn, iklam, thartmann ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: 32e20dcd43eb Author: redestad Date: 2020-03-03 12:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/32e20dcd43eb 8240263: Assertion-only call in Method::link_method affecting product builds Reviewed-by: shade, dcubed, iklam ! src/hotspot/share/oops/method.cpp Changeset: d8dbc734645b Author: hseigel Date: 2020-03-03 15:50 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/d8dbc734645b 8240324: Improve is_boot_class_loader_data() by adding simple check Summary: Check if cld is the null_cld before looking at the class loader oop Reviewed-by: coleenp ! src/hotspot/share/classfile/classLoaderData.inline.hpp Changeset: e0e5cbb61e86 Author: coleenp Date: 2020-03-03 11:19 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/e0e5cbb61e86 8225760: oop::raw_set_obj isn't needed Reviewed-by: hseigel, rkennke ! src/hotspot/share/oops/oopsHierarchy.hpp Changeset: 06b31c23a9a8 Author: fmatte Date: 2020-02-27 19:33 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/06b31c23a9a8 8239055: Wrong implementation of VMState.hasListener Summary: Correct the VMState.hasListener implementation to return WeakReference type Reviewed-by: sspitsyn, poonam ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java Changeset: ef54941dbc95 Author: mseledtsov Date: 2020-03-03 12:43 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ef54941dbc95 8235206: JFR TestCrossProcessStreaming - validate that data can be consumed while it is being produced Summary: Updated test to validate concurrent produce/consume Reviewed-by: egahlin ! test/jdk/jdk/jfr/api/consumer/streaming/TestCrossProcessStreaming.java Changeset: 522f5bb0e92b Author: xuelei Date: 2020-03-03 15:57 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/522f5bb0e92b 8233619: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 Reviewed-by: jnimeh ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java ! src/java.base/share/classes/sun/security/ssl/PostHandshakeContext.java + test/jdk/javax/net/ssl/SSLEngine/FinishedPresent.java Changeset: f6322be85592 Author: roland Date: 2020-02-21 15:01 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f6322be85592 8239367: RunThese30M.java failed due to "assert(false) failed: graph should be schedulable" Reviewed-by: thartmann, vlivanov, neliasso ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp + test/hotspot/jtreg/compiler/types/TestSubTypeCheckMacroNodeWrongMem.java Changeset: 1d4d4c9d03c2 Author: roland Date: 2020-02-20 16:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1d4d4c9d03c2 8238384: CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/gcm.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/type.hpp + test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java Changeset: a3a462ce27cd Author: bae Date: 2020-03-03 13:06 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/a3a462ce27cd 8239787: AArch64: String.indexOf may incorrectly handle empty strings Reviewed-by: aph, lmesnik, yan Contributed-by: alexey at azul.com ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp + test/hotspot/jtreg/runtime/StringIntrinsic/StringIndexOfChar.java Changeset: 6f709455592a Author: shade Date: 2020-03-04 11:50 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6f709455592a 8240511: Shenandoah: parallel safepoint workers count should be ParallelGCThreads Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java Changeset: 8797eb1fe3bf Author: jlahoda Date: 2020-03-04 13:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8797eb1fe3bf 8239575: javadoc triggers javac AssertionError for annos on modules Summary: Ensure ModuleSymbols are implicitly loaded only once in the javadoc context. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! test/langtools/jdk/javadoc/tool/modules/Modules.java Changeset: d2fc63de7876 Author: jlahoda Date: 2020-03-04 13:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d2fc63de7876 8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW Summary: Avoiding parsing of compound assignment as a type. Reviewed-by: jjg, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/parser/JavacParserTest.java Changeset: 1c06a8ee8aca Author: jlahoda Date: 2020-03-04 13:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1c06a8ee8aca 8234896: Tab completion does not work for method references in jshell. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java Changeset: b0d94da54415 Author: herrick Date: 2020-03-03 17:58 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/b0d94da54415 8237967: No proper error message when --runtime-image points to non-existent path Reviewed-by: kizune, asemenyuk, almatvee ! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/DeployParams.java ! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources.properties ! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources_zh_CN.properties ! test/jdk/tools/jpackage/share/InvalidArgTest.java Changeset: dffb6122849b Author: herrick Date: 2020-03-03 18:07 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/dffb6122849b 8237966: Creating runtime pkg requires --mac-package-identifier Reviewed-by: kizune, asemenyuk, almatvee ! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacPkgBundler.java Changeset: b77e4d778eb7 Author: herrick Date: 2020-03-03 18:10 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/b77e4d778eb7 8238692: MacOS runtime Installer issue Reviewed-by: kizune, asemenyuk, almatvee ! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java ! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacPkgBundler.java ! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties Changeset: 707abe6ca3cb Author: simonis Date: 2020-03-04 14:55 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/707abe6ca3cb 8240333: jmod incorrectly updates .jar and .jmod files during hashing Reviewed-by: martin, alanb, lancea ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Changeset: 2fc917015437 Author: shade Date: 2020-03-04 19:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/2fc917015437 8240534: Shenandoah: ditch debug safepoint timeout adjustment Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: d0b769130118 Author: jjg Date: 2020-03-04 12:58 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/d0b769130118 8239817: Eliminate use of contentContainer and friends Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testOverview/TestOverview.java Changeset: 67cc6f3948e3 Author: ccheung Date: 2020-03-04 15:34 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/67cc6f3948e3 8240481: Remove CDS usage of InstanceKlass::is_in_error_state Summary: Track the classes which fail verification during CDS dumping in DumpTimeSharedClassInfo. Reviewed-by: iklam, minqi ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: a5cea8e81879 Author: jwilhelm Date: 2020-03-05 02:02 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a5cea8e81879 Added tag jdk-15+13 for changeset 1c06a8ee8aca ! .hgtags Changeset: 501a27fff637 Author: minqi Date: 2020-03-04 21:29 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/501a27fff637 8240546: runtime/cds/appcds/TestZGCWithCDS.java fails with Graal Summary: Test failed since Graal does not work with ZGC, fixed in test to skip Graal if ZGC. Reviewed-by: ccheung ! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java Changeset: 3465ed78d670 Author: iklam Date: 2020-03-04 22:26 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/3465ed78d670 8240244: Avoid calling resolve_super_or_fail in SystemDictionary::load_shared_class Reviewed-by: redestad, lfoltan, minqi ! src/hotspot/share/classfile/classListParser.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/memory/dynamicArchive.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 187b26b1feb2 Author: njian Date: 2020-03-05 14:51 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/187b26b1feb2 8240286: [TESTBUG] Test command error in hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java Reviewed-by: kvn, thartmann Contributed-by: qi.feng at arm.com ! test/hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java Changeset: 0ba758a2b6f0 Author: dbuck Date: 2020-03-05 03:27 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/0ba758a2b6f0 8183369: RFC unconformity of HttpURLConnection with proxy Summary: HttpURLConnection retried with proxy if the connection fails on first attempt as per RFC Reviewed-by: chegar, dfuchs, vtewari Contributed-by: ravi.k.reddy at oracle.com ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: c4dea8e07b84 Author: ysuenaga Date: 2020-03-05 19:46 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/c4dea8e07b84 8240197: Cannot start JVM when $JAVA_HOME includes CJK characters Reviewed-by: iklam, stuefe, rschmelter ! src/hotspot/os/windows/os_windows.cpp Changeset: fcbf0839a86c Author: eosterlund Date: 2020-03-05 11:12 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/fcbf0839a86c 8240370: Provide Intel JCC Erratum opt-out Reviewed-by: redestad, vlivanov, thartmann ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp Changeset: 920a6239d61a Author: redestad Date: 2020-03-05 13:14 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/920a6239d61a 8240528: OopMap cleanup Reviewed-by: kvn, thartmann ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: 4074e3cce261 Author: mgronlun Date: 2020-03-05 17:55 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4074e3cce261 8239376: JFR: assert(!cld->is_unsafe_anonymous()) failed: invariant Reviewed-by: coleenp, lfoltan, hseigel ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp Changeset: fbbcf9125cef Author: shurailine Date: 2020-03-05 09:51 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/fbbcf9125cef 8240241: Add support for JCov DiffCoverage to make files Reviewed-by: erikj, ihse ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk Changeset: 3b6510b005e5 Author: lancea Date: 2020-03-05 13:56 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/3b6510b005e5 8211917: Zip FS should add META-INF/MANIFEST.FS at the start of the Zip/JAR Reviewed-by: clanger, jpai ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java + test/jdk/jdk/nio/zipfs/testng/TEST.properties + test/jdk/jdk/nio/zipfs/testng/test/ManifestOrderTest.java + test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java Changeset: e804de2e6d4a Author: vromero Date: 2020-03-05 16:46 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/e804de2e6d4a 8240454: incorrect error message: as of release 13, 'record' is a restricted type name Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/lib/combo/tools/javac/combo/Diagnostics.java ! test/langtools/lib/combo/tools/javac/combo/JavacTemplateTestBase.java ! test/langtools/tools/javac/records/RecordCompilationTests.java ! test/langtools/tools/javac/switchexpr/WrongYieldTest.out From maurizio.cimadamore at oracle.com Thu Mar 5 22:06:05 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:06:05 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052206.025M65iP000219@aojmv0008.oracle.com> Changeset: d9a9c5180e58 Author: mcimadamore Date: 2020-03-05 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/d9a9c5180e58 Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:06:51 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:06:51 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052206.025M6p4E001711@aojmv0008.oracle.com> Changeset: c352e2dd05d4 Author: mcimadamore Date: 2020-03-05 22:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/c352e2dd05d4 Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:07:14 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:07:14 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052207.025M7FY8002524@aojmv0008.oracle.com> Changeset: 1439f0dde35c Author: mcimadamore Date: 2020-03-05 22:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/1439f0dde35c Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:07:37 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:07:37 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052207.025M7bXn003862@aojmv0008.oracle.com> Changeset: 069db4509511 Author: mcimadamore Date: 2020-03-05 22:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/069db4509511 Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Thu Mar 5 22:08:00 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Mar 2020 22:08:00 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003052208.025M80jX004918@aojmv0008.oracle.com> Changeset: f5fbb0a253d6 Author: mcimadamore Date: 2020-03-05 22:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f5fbb0a253d6 Automatic merge with default - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From vicente.romero at oracle.com Fri Mar 6 00:31:32 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 06 Mar 2020 00:31:32 +0000 Subject: hg: amber/amber: add final flag to mandated record member toString Message-ID: <202003060031.0260VWRs022311@aojmv0008.oracle.com> Changeset: 2cb1afc52e6b Author: vromero Date: 2020-03-05 19:22 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/2cb1afc52e6b add final flag to mandated record member toString ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/records/RecordCompilationTests.java From mark.reinhold at oracle.com Fri Mar 6 16:41:53 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 6 Mar 2020 17:41:53 +0100 (CET) Subject: New candidate JEP: 375: Pattern Matching for instanceof (Second Preview) Message-ID: <20200306164153.E8D133194E5@eggemoggin.niobe.net> https://openjdk.java.net/jeps/375 - Mark From Sascha.Kohlmann at misterspex.de Sat Mar 7 12:40:20 2020 From: Sascha.Kohlmann at misterspex.de (Sascha Kohlmann) Date: Sat, 7 Mar 2020 12:40:20 +0000 Subject: [records] Is null back? Message-ID: <596B28B9-D51D-411D-B49D-1262127C86F8@misterspex.de> Hi to all, I hope this is the correct place for comments about Records. I've translated a Domain Model of a current project into records. The model contains a couple of immutable value objects. These are excellently suited to be implemented as records. My observations Change from old classes to records is simple for standard use cases. Dealing with different constructors is possible. Checking values and adjusting them if necessary is possible. I found it not very intuitive to use "this.value" if I don't see the instance variable. This may change later when we've more experience with records. Null collections can be replaced by empty collections, so that null must not be returned. With other null parameters, however, it is more difficult. I had got used to never giving back null since Java 8 if null is a possible input value. Instead I always return Optional. This is only possible with records if I pass Optional as parameter into the record. Nevertheless I have to check it again for null to replace it with Optional.empty() if necessary. And Optional to pass as parameter value is not intuitive even if it shows the user that the parameter is nullable. I therefore fear that there will be more NPEs if record is implemented in the same way as before. Inheritance Less problematic I see the deep dependence of name in inheritance. I have a interface Identity { String id(); } The corresponding record looks something like this: record ConcreteId(String id) implements Identity { public ConcreteId { this.id = requireNonNull(id); } } Here I have a method name that has to become a parameter name so that I can use this parameter name again as instance variable name. Deep name coupling. I'm not sure if I like it yet. Have fun :-) -isk From forax at univ-mlv.fr Sat Mar 7 13:39:10 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 7 Mar 2020 14:39:10 +0100 (CET) Subject: [records] Is null back? In-Reply-To: <596B28B9-D51D-411D-B49D-1262127C86F8@misterspex.de> References: <596B28B9-D51D-411D-B49D-1262127C86F8@misterspex.de> Message-ID: <1287778866.1178087.1583588350126.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Sascha Kohlmann" > ?: "amber-dev" > Envoy?: Samedi 7 Mars 2020 13:40:20 > Objet: [records] Is null back? > Hi to all, Hi Sacha, > > I hope this is the correct place for comments about Records. > > I've translated a Domain Model of a current project into records. The model > contains a couple of immutable value objects. These are excellently suited to > be implemented as records. > > My observations > > Change from old classes to records is simple for standard use cases. Dealing > with different constructors is possible. Checking values and adjusting them if > necessary is possible. I found it not very intuitive to use "this.value" if I > don't see the instance variable. This may change later when we've more > experience with records. > > Null collections can be replaced by empty collections, so that null must not be > returned. You can use List.copyOf()/Set.copyOf() in the compact constructor too. > > With other null parameters, however, it is more difficult. I had got used to > never giving back null since Java 8 if null is a possible input value. Instead > I always return Optional. This is only possible with records if I pass > Optional as parameter into the record. Nevertheless I have to check it again > for null to replace it with Optional.empty() if necessary. And Optional to > pass as parameter value is not intuitive even if it shows the user that the > parameter is nullable. > > I therefore fear that there will be more NPEs if record is implemented in the > same way as before. yes, Stephen Colebourne already reports that issue, the pattern with the constructor accepting null and the accessor returning an Optional is not supported. You have two solutions: - either you declare the component optional record Person(Optional name) { } - or don't declare the component Optional but burn the accessor record Person(String name /*may be null*/) { public String name() { throw new UnsupportedOperationException("name is optional"); } public Optional optionalName() { return Optional.ofNullable(name); } } the problem with the second solution is that framework that uses reflection will use the accessor. > > Inheritance > > Less problematic I see the deep dependence of name in inheritance. I have a > > interface Identity { > String id(); > } > > The corresponding record looks something like this: > > record ConcreteId(String id) implements Identity { > public ConcreteId { > this.id = requireNonNull(id); > } > } > > > Here I have a method name that has to become a parameter name so that I can use > this parameter name again as instance variable name. Deep name coupling. I'm > not sure if I like it yet. A record component is not a parameter despite the record syntax using parenthesis, it's a record component, something which is public and part of the public API, changing its name is not a backward compatible change. Moreover, you can have less coupling if you want: interface Identity { String id(); } record ConcreteId(String value) implements Identity { public ConcreteId { this.value = requireNonNull(value); } public String id() { return value; } } > > Have fun :-) > > -isk regards, R?mi From youngty1997 at gmail.com Sat Mar 7 14:41:08 2020 From: youngty1997 at gmail.com (Ty Young) Date: Sat, 7 Mar 2020 08:41:08 -0600 Subject: Throwing exceptions from records In-Reply-To: <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> Message-ID: <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> On 3/5/20 2:50 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Ty Young" >> ?: "amber-dev" >> Envoy?: Jeudi 5 Mars 2020 21:04:40 >> Objet: Re: Throwing exceptions from records >> On 3/5/20 1:39 PM, Vicente Romero wrote: >>> Hi Ty, >>> >>> On 3/5/20 2:12 PM, Ty Young wrote: >>>> Actually going to expand this a bit after messing around with records... >>>> >>>> >>>> How is records supposed to work beyond the most basic usage of >>>> Point(int x, int y)? There isn't much information out there for the >>>> more advanced usages so I'm confused. >>>> >>>> >>>> To go into more detail, I'm trying to convert this: >>>> >>>> >>>> https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java >>>> >>>> >>>> >>>> which doesn't seem possible as-is because you can't throw exceptions >>>> from record constructors. >>> you can't throw exceptions from _canonical_ record constructors, being >>> a canonical record constructor the one with the same signature as the >>> record header but you can do: >>> >>> record R(int i) { >>> ??? public R() throws Exception {? // not a canonical constructor so >>> no restriction >>> ??????? this(someMethodReturningIntThatThrows());? // invoking the >>> canonical constructor >>> ??? } >>> } >>>> >>>> Furthermore there seems to be some constraint where constructor >>>> arguments have to match the record argument signature. Why does that >>>> even matter? >>> only the canonical but you can declare other constructors with a >>> different signature >> >> The problem is that the constructor arguments require preprocessing but >> you can't do that since the canonical constructor has to be called >> first. I suppose static methods could be used to do that but that feels >> like a bad workaround for something that will probably be fairly common. > It's common to avoid to throw checked exceptions in constructor because instead of first creating the object (with new) and then throwing the exception, it's better to throw the exception before the creation of the object. The usual alternatives are as you said either use a static method which is very common when dealing with IOException or use an unchecked exception instead. Not really my choice. I've asked JDK developers to add an alternative method that doesn't throw the exception and have been ignored multiple times now. I'm not even the only one who has asked for an alternative either. Seems to be a fairly common response(or lack thereof)... > > and as a meta comment, debugging constructors is hard because you are at the point where every objects is mutable, it's a good idea to only have initialization code in a constructor (this.foo = foo) or preconditions (Objects.reuireNonNull(...)), so to have a code is so simple that you will never have a bug in a constructor. If you follow that rule, i promise you will never be angry anymore :) Not really relevant. Records shouldn't prevent people from doing basic in-constructor processing. The current record implementation is foobar. Anything more than the basic "Point" example is too much for the current record implementation, it seems. > > regards, > R?mi From forax at univ-mlv.fr Sat Mar 7 16:05:20 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 7 Mar 2020 17:05:20 +0100 (CET) Subject: Throwing exceptions from records In-Reply-To: <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> Message-ID: <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Ty Young" > ?: "amber-dev" > Envoy?: Samedi 7 Mars 2020 15:41:08 > Objet: Re: Throwing exceptions from records > On 3/5/20 2:50 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Ty Young" >>> ?: "amber-dev" >>> Envoy?: Jeudi 5 Mars 2020 21:04:40 >>> Objet: Re: Throwing exceptions from records >>> On 3/5/20 1:39 PM, Vicente Romero wrote: >>>> Hi Ty, >>>> >>>> On 3/5/20 2:12 PM, Ty Young wrote: >>>>> Actually going to expand this a bit after messing around with records... >>>>> >>>>> >>>>> How is records supposed to work beyond the most basic usage of >>>>> Point(int x, int y)? There isn't much information out there for the >>>>> more advanced usages so I'm confused. >>>>> >>>>> >>>>> To go into more detail, I'm trying to convert this: >>>>> >>>>> >>>>> https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java >>>>> >>>>> >>>>> >>>>> which doesn't seem possible as-is because you can't throw exceptions >>>>> from record constructors. >>>> you can't throw exceptions from _canonical_ record constructors, being >>>> a canonical record constructor the one with the same signature as the >>>> record header but you can do: >>>> >>>> record R(int i) { >>>> ??? public R() throws Exception {? // not a canonical constructor so >>>> no restriction >>>> ??????? this(someMethodReturningIntThatThrows());? // invoking the >>>> canonical constructor >>>> ??? } >>>> } >>>>> >>>>> Furthermore there seems to be some constraint where constructor >>>>> arguments have to match the record argument signature. Why does that >>>>> even matter? >>>> only the canonical but you can declare other constructors with a >>>> different signature >>> >>> The problem is that the constructor arguments require preprocessing but >>> you can't do that since the canonical constructor has to be called >>> first. I suppose static methods could be used to do that but that feels >>> like a bad workaround for something that will probably be fairly common. >> It's common to avoid to throw checked exceptions in constructor because instead >> of first creating the object (with new) and then throwing the exception, it's >> better to throw the exception before the creation of the object. The usual >> alternatives are as you said either use a static method which is very common >> when dealing with IOException or use an unchecked exception instead. > > > Not really my choice. I've asked JDK developers to add an alternative > method that doesn't throw the exception and have been ignored multiple > times now. I'm not even the only one who has asked for an alternative > either. > > > Seems to be a fairly common response(or lack thereof)... in this specific case, why not catching NoSuchMethodException and re-throw a NoSuchMethodError ? > > >> >> and as a meta comment, debugging constructors is hard because you are at the >> point where every objects is mutable, it's a good idea to only have >> initialization code in a constructor (this.foo = foo) or preconditions >> (Objects.reuireNonNull(...)), so to have a code is so simple that you will >> never have a bug in a constructor. If you follow that rule, i promise you will >> never be angry anymore :) > > > Not really relevant. Records shouldn't prevent people from doing basic > in-constructor processing. The current record implementation is foobar. I respectfully disagree. Records doesn't have to support all scenarii supported by classes, otherwise you will end up with records being classes. A record is a data carrier, with the data being created before and stuff into the data carrier, so there is no need to support a constructor with checked exceptions. > Anything more than the basic "Point" example is too much for the current > record implementation, it seems. I would love this to be true, codes using records will be so easy to read and understand. regards, R?mi From brian.goetz at oracle.com Sat Mar 7 22:57:58 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 7 Mar 2020 17:57:58 -0500 Subject: [records] Is null back? In-Reply-To: <596B28B9-D51D-411D-B49D-1262127C86F8@misterspex.de> References: <596B28B9-D51D-411D-B49D-1262127C86F8@misterspex.de> Message-ID: <771d7c82-ff89-085b-c7ad-29460561ecb8@oracle.com> Is null back?? It never left us! In addition to the other answers you got, I'd add: > I found it not very intuitive to use "this.value" if I don't see the instance variable. > > record ConcreteId(String id) implements Identity { > public ConcreteId { > this.id = requireNonNull(id); > } > } > The intention is that you don't have to say ``this` here at all, and probably shouldn't.?? The compact constructor commits its arguments to the same-named fields at the end of the ctor, if they are DU at the end of the ctor.? So the better way to do this would be: record ConcreteId(String id) implements Identity { public ConcreteId { id = requireNonNull(id); } } as constructor arguments are mutable. Think of the body of the compact ctor as a transform on its parameters, which are then committed to the state of the record. From forax at univ-mlv.fr Sat Mar 7 23:26:43 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 8 Mar 2020 00:26:43 +0100 (CET) Subject: [records] Is null back? In-Reply-To: <771d7c82-ff89-085b-c7ad-29460561ecb8@oracle.com> References: <596B28B9-D51D-411D-B49D-1262127C86F8@misterspex.de> <771d7c82-ff89-085b-c7ad-29460561ecb8@oracle.com> Message-ID: <2100135057.1224975.1583623603613.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Sascha Kohlmann" , "amber-dev" > Envoy?: Samedi 7 Mars 2020 23:57:58 > Objet: Re: [records] Is null back? > Is null back?? It never left us! > > In addition to the other answers you got, I'd add: > > >> I found it not very intuitive to use "this.value" if I don't see the instance >> variable. >> >> record ConcreteId(String id) implements Identity { >> public ConcreteId { >> this.id = requireNonNull(id); >> } >> } >> > > The intention is that you don't have to say ``this` here at all, and > probably shouldn't.?? The compact constructor commits its arguments to > the same-named fields at the end of the ctor, if they are DU at the end > of the ctor.? So the better way to do this would be: > > record ConcreteId(String id) implements Identity { > public ConcreteId { > id = requireNonNull(id); > } > } > > as constructor arguments are mutable. Think of the body of the compact ctor as > a transform on its parameters, which are then committed to the state of the > record. or even record ConcreteId(String id) implements Identity { public ConcreteId { requireNonNull(id); } } as a trivia, in both case, the generated bytecode is bigger than the initial code of Sascha. R?mi From youngty1997 at gmail.com Sun Mar 8 00:51:48 2020 From: youngty1997 at gmail.com (Ty Young) Date: Sat, 7 Mar 2020 18:51:48 -0600 Subject: Throwing exceptions from records In-Reply-To: <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> Message-ID: <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> On 3/7/20 10:05 AM, Remi Forax wrote: > ----- Mail original ----- >> De: "Ty Young" >> ?: "amber-dev" >> Envoy?: Samedi 7 Mars 2020 15:41:08 >> Objet: Re: Throwing exceptions from records >> On 3/5/20 2:50 PM, Remi Forax wrote: >>> ----- Mail original ----- >>>> De: "Ty Young" >>>> ?: "amber-dev" >>>> Envoy?: Jeudi 5 Mars 2020 21:04:40 >>>> Objet: Re: Throwing exceptions from records >>>> On 3/5/20 1:39 PM, Vicente Romero wrote: >>>>> Hi Ty, >>>>> >>>>> On 3/5/20 2:12 PM, Ty Young wrote: >>>>>> Actually going to expand this a bit after messing around with records... >>>>>> >>>>>> >>>>>> How is records supposed to work beyond the most basic usage of >>>>>> Point(int x, int y)? There isn't much information out there for the >>>>>> more advanced usages so I'm confused. >>>>>> >>>>>> >>>>>> To go into more detail, I'm trying to convert this: >>>>>> >>>>>> >>>>>> https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/functions/nvmlInit.java >>>>>> >>>>>> >>>>>> >>>>>> which doesn't seem possible as-is because you can't throw exceptions >>>>>> from record constructors. >>>>> you can't throw exceptions from _canonical_ record constructors, being >>>>> a canonical record constructor the one with the same signature as the >>>>> record header but you can do: >>>>> >>>>> record R(int i) { >>>>> ??? public R() throws Exception {? // not a canonical constructor so >>>>> no restriction >>>>> ??????? this(someMethodReturningIntThatThrows());? // invoking the >>>>> canonical constructor >>>>> ??? } >>>>> } >>>>>> Furthermore there seems to be some constraint where constructor >>>>>> arguments have to match the record argument signature. Why does that >>>>>> even matter? >>>>> only the canonical but you can declare other constructors with a >>>>> different signature >>>> The problem is that the constructor arguments require preprocessing but >>>> you can't do that since the canonical constructor has to be called >>>> first. I suppose static methods could be used to do that but that feels >>>> like a bad workaround for something that will probably be fairly common. >>> It's common to avoid to throw checked exceptions in constructor because instead >>> of first creating the object (with new) and then throwing the exception, it's >>> better to throw the exception before the creation of the object. The usual >>> alternatives are as you said either use a static method which is very common >>> when dealing with IOException or use an unchecked exception instead. >> >> Not really my choice. I've asked JDK developers to add an alternative >> method that doesn't throw the exception and have been ignored multiple >> times now. I'm not even the only one who has asked for an alternative >> either. >> >> >> Seems to be a fairly common response(or lack thereof)... > in this specific case, why not catching NoSuchMethodException and re-throw a NoSuchMethodError ? What do you mean? If you try-catch something then it'd be non-final. > >> >>> and as a meta comment, debugging constructors is hard because you are at the >>> point where every objects is mutable, it's a good idea to only have >>> initialization code in a constructor (this.foo = foo) or preconditions >>> (Objects.reuireNonNull(...)), so to have a code is so simple that you will >>> never have a bug in a constructor. If you follow that rule, i promise you will >>> never be angry anymore :) >> >> Not really relevant. Records shouldn't prevent people from doing basic >> in-constructor processing. The current record implementation is foobar. > I respectfully disagree. Records doesn't have to support all scenarii supported by classes, otherwise you will end up with records being classes. I didn't say it did? > A record is a data carrier, with the data being created before and stuff into the data carrier, so there is no need to support a constructor with checked exceptions. Who said the data had to be constructed before the record? I've watched dozens of presentations on Records via JDK developers and not once was this ever said. The only two things that make something a record is if: A. it can be reconstructed repeatably given the same arguments(somewhat like a pure function). and B. all instance fields are always final. Never mind the issues with A(it can't be enforced), none of that says anything about how record fields are set. It sure as heck never says that the first statement of non canonical constructors must call the canonical constructor first, nor does it specify whether or not exceptions can or should be throwable. > >> Anything more than the basic "Point" example is too much for the current >> record implementation, it seems. > I would love this to be true, codes using records will be so easy to read and understand. Right, because any and all meaningful logic is just thrown in other places making them more complicated. > > regards, > R?mi From kasperni at gmail.com Sun Mar 8 09:10:15 2020 From: kasperni at gmail.com (Kasper Nielsen) Date: Sun, 8 Mar 2020 09:10:15 +0000 Subject: Throwing exceptions from records In-Reply-To: <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> Message-ID: > > Right, because any and all meaningful logic is just thrown in other > places making them more complicated. > I took a look at one of the classes you are trying to convert to a record [1]. And it really looks like a really poor fit for record conversion. What exactly are you trying to accomplish? Avoid writing a single getter? Because something like equals() and toString() doesn't really make sense. Also, by converting to records you would end up exposing the VarHandle which I assume is something you would actually want to encapsulate? On top of that, you have a set method, which I find really weird given that records signal pure data carriers. And maybe go a bit easy on the confrontational tone in your emails. It won't get you any further on amber-dev then it did on panama-dev. /Kasper From youngty1997 at gmail.com Mon Mar 9 19:27:10 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 9 Mar 2020 14:27:10 -0500 Subject: Throwing exceptions from records In-Reply-To: References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> Message-ID: On 3/8/20 4:10 AM, Kasper Nielsen wrote: >> Right, because any and all meaningful logic is just thrown in other >> places making them more complicated. >> > I took a look at one of the classes you are trying to convert to a record [1]. > And it really looks like a really poor fit for record conversion. Why? > What exactly > are you trying to accomplish? Avoid writing a single getter? No. The point is to signify that the classes merely contain data. > Because something > like equals() and toString() doesn't really make sense. Again, why? You claim things but provide zero reasons as to why. > Also, by converting to > records you would end up exposing the VarHandle which I assume is something > you would actually want to encapsulate? It's exposed anyway? > On top of that, you have a set method, > which I find really weird given that records signal pure data carriers. There is no "set" method, only an action, "call". And what is a "pure data carrier" exactly? I don't see any concrete definition by anyone. No one said you couldn't have actions or setters which modify a records field's fields. Also, why would a "pure" data carrier then need to have the ability to implement interfaces? It introduces problems where an interface method "getX()" could be different than just "x()". > /Kasper From brian.goetz at oracle.com Mon Mar 9 19:41:19 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 9 Mar 2020 15:41:19 -0400 Subject: Throwing exceptions from records In-Reply-To: References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> Message-ID: <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> Ty; I think this discussion has largely run its course, and is threatening to stray outside of the bounds of what this list is for. As a reminder, this list is for those involved in the _development_ of the Amber features.? We consider "experience reports" to be a valid (and often, highly valuable) contribution from that perspective, to the extent they are grounded in the concrete: "I tried X, and Y worked, but Z didn't." I'd summarize the useful part of your feedback as follows: ?- It might be reasonable to allow record constructors to throw checked exceptions, since they already can throw unchecked exceptions (though, you don't really provide much in the way of concrete examples, just that you are worried about calling exception-throwing code from the ctor (though, as Kasper said, this is a sign you might be using the wrong tool in the first place)) Which is fine as far as it goes, and we'll take a note to discuss this in the EG.? The rest is, let's just say, "out of scope" for this list. You also received some excellent advice from more experienced developers such as Remi and Kasper, which you seem more interested in arguing with than being educated by.? Which is fine, but don't do it here, that's not what this list is for. On 3/9/2020 3:27 PM, Ty Young wrote: > > On 3/8/20 4:10 AM, Kasper Nielsen wrote: >>> Right, because any and all meaningful logic is just thrown in other >>> places making them more complicated. >>> >> I took a look at one of the classes you are trying to convert to a >> record [1]. >> And it really looks like a really poor fit for record conversion. > > > Why? > > >> ? What exactly >> are you trying to accomplish? Avoid writing a single getter? > > > No. The point is to signify that the classes merely contain data. > > >> ? Because something >> like equals() and toString() doesn't really make sense. > > > Again, why? You claim things but provide zero reasons as to why. > > >> ? Also, by converting to >> records you would end up exposing the VarHandle which I assume is >> something >> you would actually want to encapsulate? > > > It's exposed anyway? > > >> ? On top of that, you have a set method, >> which I find really weird given that records signal pure data carriers. > > > There is no "set" method, only an action, "call". > > > And what is a "pure data carrier" exactly? I don't see any concrete > definition by anyone. No one said you couldn't have actions or setters > which modify a records field's fields. > > > Also, why would a "pure" data carrier then need to have the ability to > implement interfaces? It introduces problems where an interface method > "getX()" could be different than just "x()". > > >> /Kasper From youngty1997 at gmail.com Mon Mar 9 20:18:56 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 9 Mar 2020 15:18:56 -0500 Subject: Throwing exceptions from records In-Reply-To: <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> Message-ID: On 3/9/20 2:41 PM, Brian Goetz wrote: > Ty; > > I think this discussion has largely run its course, and is threatening > to stray outside of the bounds of what this list is for. I was told that amber-dev was for discussion of records. I guess there was a miscommunication? > > As a reminder, this list is for those involved in the _development_ of > the Amber features.? We consider "experience reports" to be a valid > (and often, highly valuable) contribution from that perspective, to > the extent they are grounded in the concrete: "I tried X, and Y > worked, but Z didn't." I've converted several classes to records(although there isn't much of a different between them). Here is [1] converted to record: https://pastebin.com/V1eHehc0 As said before, all meaningful logic is now gone from the class. At this point individual files no longer need to exist since all NativeFunction implementations require the same fields and records are too limiting as-is. You might as well have a "NativeFunctionRecord" record that takes care of everything, with static methods that do the required object creation to pass to the canonical constructor. > > I'd summarize the useful part of your feedback as follows: > > ?- It might be reasonable to allow record constructors to throw > checked exceptions, since they already can throw unchecked exceptions > (though, you don't really provide much in the way of concrete > examples, just that you are worried about calling exception-throwing > code from the ctor (though, as Kasper said, this is a sign you might > be using the wrong tool in the first place)) And the ability to have a no-args constructor that sets everything(see above link as to why this would be nice). This is possible technically but the issue is that the canonical constructor has to be called first. > > Which is fine as far as it goes, and we'll take a note to discuss this > in the EG.? The rest is, let's just say, "out of scope" for this list. > > You also received some excellent advice from more experienced > developers such as Remi and Kasper, which you seem more interested in > arguing with than being educated by.? Which is fine, but don't do it > here, that's not what this list is for. Surely education requires giving explanations, not simply saying "no"? I asked why it wasn't a good fit for records and you say it's "out-of-scope" of this list. Again, AFAIK, the only two requirements for a class to be a record are: 1. All fields must be final and 2. You must be able to recreate a record using the same inputs(or lack thereof). No one has said otherwise nor has anyone layed down or linked to any other design documents that say my use case is wrong or invalid. I actually tried looking for some online article showing a more advanced usage of records and 75% of the articles just copy/pasted the Point example from the JEP. There wasn't much information on what does and doesn't make for a record other than those two things, which my classes do seem to fall under. Is the Point example really it? It feels so simple to the point(pun not intended) of feeling being wrong. Yes, records are not classes and that's perfectly fine and totally not the issue. The issue is the implementation details like forcing a call to the canonical constructor first or not being able to throw exceptions. > > > > > > On 3/9/2020 3:27 PM, Ty Young wrote: >> >> On 3/8/20 4:10 AM, Kasper Nielsen wrote: >>>> Right, because any and all meaningful logic is just thrown in other >>>> places making them more complicated. >>>> >>> I took a look at one of the classes you are trying to convert to a >>> record [1]. >>> And it really looks like a really poor fit for record conversion. >> >> >> Why? >> >> >>> ? What exactly >>> are you trying to accomplish? Avoid writing a single getter? >> >> >> No. The point is to signify that the classes merely contain data. >> >> >>> ? Because something >>> like equals() and toString() doesn't really make sense. >> >> >> Again, why? You claim things but provide zero reasons as to why. >> >> >>> ? Also, by converting to >>> records you would end up exposing the VarHandle which I assume is >>> something >>> you would actually want to encapsulate? >> >> >> It's exposed anyway? >> >> >>> ? On top of that, you have a set method, >>> which I find really weird given that records signal pure data carriers. >> >> >> There is no "set" method, only an action, "call". >> >> >> And what is a "pure data carrier" exactly? I don't see any concrete >> definition by anyone. No one said you couldn't have actions or >> setters which modify a records field's fields. >> >> >> Also, why would a "pure" data carrier then need to have the ability >> to implement interfaces? It introduces problems where an interface >> method "getX()" could be different than just "x()". >> >> >>> /Kasper > From vicente.romero at oracle.com Mon Mar 9 20:22:38 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 09 Mar 2020 20:22:38 +0000 Subject: hg: amber/amber: 8236598: make sure that the compiler issues an error for any modifier applied to record components Message-ID: <202003092022.029KMdL9026302@aojmv0008.oracle.com> Changeset: 69545390018d Author: vromero Date: 2020-03-09 16:21 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/69545390018d 8236598: make sure that the compiler issues an error for any modifier applied to record components ! test/langtools/tools/javac/records/RecordCompilationTests.java From brian.goetz at oracle.com Mon Mar 9 21:12:29 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 9 Mar 2020 17:12:29 -0400 Subject: Throwing exceptions from records In-Reply-To: References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> Message-ID: >> I think this discussion has largely run its course, and is >> threatening to stray outside of the bounds of what this list is for. > > > I was told that amber-dev was for discussion of records. I guess there > was a miscommunication? Yes, perhaps the confusion is over the nature of said "discussion". The charter of the -dev lists is for collaboration and discussion on the _development_ of features in OpenJDK, not "any discussion pertaining to records".?? As mentioned, constructive experience reports are always welcome, but they need to stay within the bounds of relevance and constructiveness, and you've surely found the bounds of both, and you're being told to dial it back. For the record, a good guideline for when a non-development-related comment is in bounds is: Is this telling the design or development team something they are unlikely to already know?? Reporting bugs almost always is; sharing concrete experience often is; undirected complaining about features or disagreement with specific decisions usually is not (we are already well aware that some people would prefer a different choice for nearly any decision), and complaining about process almost never is.? I realize interpreting these lines require judgment, so this is your notice that you've gone way over these lines.? (And, based on what's happened over on panama-dev, not your first notice, or even close.) > No one has said otherwise nor has anyone layed down or linked to any > other design documents that say my use case is wrong or invalid. I think if you actually read what's been discussed on these lists, you'd see that there has been a significant amount of discussion on the "design center" for this feature, which could have informed your judgment about whether you were working with, or against, the grain of this feature.? (And others, who had been following, tried to suggest maybe you were holding it wrong -- and instead of thanking them or constructively engaging, you just argued and complained more.)? There is plenty of information out there, but it might take some work to find.? (But not that much.)? Participating in the development is advanced stuff, and if you want to play, you have to suit up.? (Or, if you don't want to, that's fine -- but then please don't bother those who are doing the work.) Turning to your code, I agree with Kasper's intuition that you are trying to use records for something they were not intended for.? The design center for records is (as has been stated many times) "nominal tuples".? Is `nvmlInit` effectively a tuple?? Are the state-based equals, hashCode, and toString methods a natural fit for the domain?? Is the canonical constructor enforcing any necessary invariants?? Are you getting any benefit _at all_ from declaring as a record?? I don't think so.? These are signs that this isn't the tool you are looking for.? (BTW, you can use the compact form of the constructor here; you don't need to write out `this.x = x`.)? Or, perhaps you might consider whether records are helpful as the _implementation detail_ of your class, by wrapping a record with the API you actually want to expose? I suggest you go off and think about this stuff for a few weeks, read what you can about the subject, and then if you still have questions, and can express them constructively, consider trying again. From youngty1997 at gmail.com Mon Mar 9 23:09:40 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 9 Mar 2020 18:09:40 -0500 Subject: Throwing exceptions from records In-Reply-To: References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> Message-ID: <07b0d764-7485-8f73-9514-ab735ef11afb@gmail.com> On 3/9/20 4:12 PM, Brian Goetz wrote: > > >>> I think this discussion has largely run its course, and is >>> threatening to stray outside of the bounds of what this list is for. >> >> >> I was told that amber-dev was for discussion of records. I guess >> there was a miscommunication? > > Yes, perhaps the confusion is over the nature of said "discussion". > The charter of the -dev lists is for collaboration and discussion on > the _development_ of features in OpenJDK, not "any discussion > pertaining to records". Is there a mailing list that is? I posted this on jdk-dev originally because it seemed to be a more laid-back, general list but, as I said, was told to post here. Right now there is discussion on preview features on jdk-dev that continues despite the official response seemingly being a resounding "no" to multiple people's requests for an official preview system. > ?? As mentioned, constructive experience reports are always welcome, > but they need to stay within the bounds of relevance and > constructiveness, and you've surely found the bounds of both, and > you're being told to dial it back. > > For the record, a good guideline for when a non-development-related > comment is in bounds is: Is this telling the design or development > team something they are unlikely to already know?? Reporting bugs > almost always is; sharing concrete experience often is; undirected > complaining about features or disagreement with specific decisions > usually is not (we are already well aware that some people would > prefer a different choice for nearly any decision), and complaining > about process almost never is.? I realize interpreting these lines > require judgment, so this is your notice that you've gone way over > these lines.? (And, based on what's happened over on panama-dev, not > your first notice, or even close.) I would be interested in a breakdown of such a judgement. I have been subscribed to many JDK mailing lists and have seen many presentations and/or emails by you and/or others wherein: 1. Some JDK developers being downright condescending(see the preview API discussion on jdk-dev for an example, wasn't even me calling it out) 2. Snarky comments between a JDK developer and another mailing list user about other mailing list members 3. Inappropriate, snide Jokes aimed at people on mailing lists during conferences/presentations 4. The deliberate attempt to kill civil(keyword here) discussion created by other people from JDK developers Yet no warnings or "judgements" have been given. Point is, JDK developers sometimes act and conduct themselves in ways that are seemingly unprofessional, unwelcoming, uncivil yet expect professional, welcoming, and civil behaviour from those outside the JDK developer circle. None of this is good for civil, rational discussion, yet it continues. None of this is to say that I'm void of wrongdoing. I'm just saying, "rules for you, not for us" is what this feels like. Anyway, majorly off-topic, I know. > >> No one has said otherwise nor has anyone layed down or linked to any >> other design documents that say my use case is wrong or invalid. > > I think if you actually read what's been discussed on these lists, > you'd see that there has been a significant amount of discussion on > the "design center" for this feature, which could have informed your > judgment about whether you were working with, or against, the grain of > this feature. I didn't know it was expected that anyone interested in participating in JDK mailing list discussion must be subscribed to every single list and had to be caught up on reading every single thread. For the record, people other than myself have complained on panama-dev that just keeping up with Project Panama was too much for them... so I'm not the only one who is behind. Some people do Java programming on the side and just don't have time for mailing lists. I personally generally regard Project Amber to be that project where all the "bad" Java features are conjured up so I never joined, but thought records might be different. > ? (And others, who had been following, tried to suggest maybe you were > holding it wrong -- and instead of thanking them or constructively > engaging, you just argued and complained more.)? There is plenty of > information out there, but it might take some work to find. (But not > that much.)? Participating in the development is advanced stuff, and > if you want to play, you have to suit up.? (Or, if you don't want to, > that's fine -- but then please don't bother those who are doing the > work.) I was genuinely asking for clarification as to why what they said was true. Apologies if that is how it came across, it 100% wasn't. > > Turning to your code, I agree with Kasper's intuition that you are > trying to use records for something they were not intended for. The > design center for records is (as has been stated many times) "nominal > tuples".? Is `nvmlInit` effectively a tuple?? Are the state-based > equals, hashCode, and toString methods a natural fit for the domain?? > Is the canonical constructor enforcing any necessary invariants?? Are > you getting any benefit _at all_ from declaring as a record?? I don't > think so.? These are signs that this isn't the tool you are looking > for.? (BTW, you can use the compact form of the constructor here; you > don't need to write out `this.x = x`.)? Or, perhaps you might consider > whether records are helpful as the _implementation detail_ of your > class, by wrapping a record with the API you actually want to expose? OK, thank you for the explanation. I guess when i read "record" I associate it with a document such as a medical(or similar) record... that is to say, something that is frozen in time and could be reproduced given the same information. Random people elsewhere do mention tuples when in conjunction with records, yes, but I didn't think that was the true purpose but rather a side affect or bonus feature. I take it the name is frozen and there is zero considerations for naming it to something more true to the intended meaning(tuple)? > > I suggest you go off and think about this stuff for a few weeks, read > what you can about the subject, and then if you still have questions, > and can express them constructively, consider trying again. > From youngty1997 at gmail.com Mon Mar 9 23:20:44 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 9 Mar 2020 18:20:44 -0500 Subject: Throwing exceptions from records In-Reply-To: <07b0d764-7485-8f73-9514-ab735ef11afb@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> <07b0d764-7485-8f73-9514-ab735ef11afb@gmail.com> Message-ID: > OK, thank you for the explanation. I guess when i read "record" I > associate it with a document such as a medical(or similar) record... > that is to say, something that is frozen in time and could be > reproduced given the same information. Random people elsewhere do > mention tuples when in conjunction with records, yes, but I didn't > think that was the true purpose but rather a side affect or bonus > feature. I take it the name is frozen and there is zero considerations > for naming it to something more true to the intended meaning(tuple)? > > To be clear, I'm talking about minor, detail implementation difference between the two. Yes, I realize that a "record" is a "tuple" but the specific form, at least in my mind, can be slightly different between the two. From brian.goetz at oracle.com Tue Mar 10 01:06:30 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 9 Mar 2020 21:06:30 -0400 Subject: Throwing exceptions from records In-Reply-To: <07b0d764-7485-8f73-9514-ab735ef11afb@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> <2a82e14e-f321-9b20-e1f3-0a4189aa6fbc@gmail.com> <016094ee-94c3-ed1a-f9c7-abc42f82eeeb@gmail.com> <624721015.562685.1583441421809.JavaMail.zimbra@u-pem.fr> <06c51361-76ef-de36-a2cb-8f48d123c720@gmail.com> <1829607927.1190260.1583597120075.JavaMail.zimbra@u-pem.fr> <179eee95-1c81-35bf-f881-892632e4444a@gmail.com> <60b32cc2-a185-15bf-e602-4f81db589650@oracle.com> <07b0d764-7485-8f73-9514-ab735ef11afb@gmail.com> Message-ID: <48a313e8-ef87-f2d4-a2f7-1f191ebd84d9@oracle.com> >> Yes, perhaps the confusion is over the nature of said "discussion". >> The charter of the -dev lists is for collaboration and discussion on >> the _development_ of features in OpenJDK, not "any discussion >> pertaining to records". > > > Is there a mailing list that is? Not one that is hosted at OpenJDK.? But you have the whole rest of the internet -- StackOverflow, Reddit, Twitter -- to choose from. And, one can generally get away with asking questions here about how things are intended to be used, or the rationale behind a decision -- if you can do it constructively and respectfully. > OK, thank you for the explanation. I guess when i read "record" I > associate it with a document such as a medical(or similar) record... > that is to say, something that is frozen in time and could be > reproduced given the same information. Random people elsewhere do > mention tuples when in conjunction with records, yes, but I didn't > think that was the true purpose but rather a side affect or bonus > feature. You might find this summary useful: https://www.infoq.com/articles/java-14-feature-spotlight/ > I take it the name is frozen and there is zero considerations for > naming it to something more true to the intended meaning(tuple)? Yes, the naming discussion has been had, and yes, tuple was considered.? The consensus was that calling it "tuple" would engender a "but that's not what a tuple is" response from those who are used to tuples being structural, not nominal, and that this would be a distraction.? So we chose a name that was a little less loaded, but was still associated with nominal, fixed-sized-and-type sequences (think records in a relational database.)? Coincidentally, the C# folks went through the same process and independently came up with the name "record". From jan.lahoda at oracle.com Tue Mar 10 14:35:46 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 10 Mar 2020 14:35:46 +0000 Subject: hg: amber/amber: Merging recent default branch changes to the sealed-types branch. Message-ID: <202003101435.02AEZltB008571@aojmv0008.oracle.com> Changeset: f3fbbdf71b59 Author: jlahoda Date: 2020-03-10 15:34 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f3fbbdf71b59 Merging recent default branch changes to the sealed-types branch. - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 ! make/autoconf/spec.gmk.in ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.hpp - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From maurizio.cimadamore at oracle.com Tue Mar 10 14:41:22 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 10 Mar 2020 14:41:22 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202003101441.02AEfNPS015903@aojmv0008.oracle.com> Changeset: 0f3b2aa1e1a1 Author: mcimadamore Date: 2020-03-10 14:41 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/0f3b2aa1e1a1 Automatic merge with sealed-types ! .hgtags ! doc/building.html ! doc/testing.html ! doc/testing.md - make/Help.gmk ! make/Images.gmk ! make/RunTests.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 ! make/autoconf/spec.gmk.in ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/interp_masm_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/s390/interp_masm_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/sparc/interp_masm_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/solaris/os_solaris.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/code/vtableStubs.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/zVerify.cpp ! src/hotspot/share/interpreter/bytecodeInterpreter.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/oopsHierarchy.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/vmError.cpp - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/conf/security/java.security ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java - src/jdk.internal.vm.compiler/.mx.graal/.project - src/jdk.internal.vm.compiler/.mx.graal/.pydevproject - src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs - src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py - src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py - src/jdk.internal.vm.compiler/.mx.graal/outputparser.py - src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py - src/jdk.internal.vm.compiler/.mx.graal/suite.py - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64LIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/GraalOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraalCompilerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/MonitorSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Move.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayIndexOfOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.test/src/org/graalvm/compiler/loop/test/LoopPartialUnrollTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/WriteBarrierAdditionPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/GraalTest.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ParamTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! test/hotspot/jtreg/ProblemList.txt - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh ! test/jdk/ProblemList.txt ! test/langtools/TEST.ROOT - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/lib/combo/tools/javac/combo/Diagnostics.java ! test/langtools/lib/combo/tools/javac/combo/JavacTemplateTestBase.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/records/RecordCompilationTests.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java + test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java From vicente.romero at oracle.com Wed Mar 11 21:16:00 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 11 Mar 2020 21:16:00 +0000 Subject: hg: amber/amber: 2 new changesets Message-ID: <202003112116.02BLG1Q2000854@aojmv0008.oracle.com> Changeset: 02362283ad58 Author: vromero Date: 2020-03-10 19:32 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/02362283ad58 fixing test after recent changes ! test/langtools/tools/javac/processing/model/element/TestRecordDesugar.java Changeset: 457065a22ac8 Author: vromero Date: 2020-03-11 15:53 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/457065a22ac8 8240826: records: mandated members should get the accessibility of the enclosing record type ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/langtools/tools/javac/diags/examples/CanonicalConstructorMustBePublic.java ! test/langtools/tools/javac/processing/model/element/TestRecordDesugar.java ! test/langtools/tools/javac/records/RecordCompilationTests.java ! test/langtools/tools/javac/records/RecordMemberTests.java ! test/langtools/tools/javac/records/VarargsRecordsTest.java From maurizio.cimadamore at oracle.com Thu Mar 12 22:01:08 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 12 Mar 2020 22:01:08 +0000 Subject: hg: amber/amber: 107 new changesets Message-ID: <202003122201.02CM1Elw002235@aojmv0008.oracle.com> Changeset: 5a58d0939974 Author: darcy Date: 2020-03-05 15:07 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/5a58d0939974 8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 attribute Reviewed-by: bpb ! src/java.base/share/classes/java/math/RoundingMode.java Changeset: 104476d44ee0 Author: dnsimon Date: 2020-03-05 16:32 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/104476d44ee0 8240538: [JVMCI] add test for JVMCI ConstantPool class Reviewed-by: kvn, iignatyev + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantPoolTest.java Changeset: 92cf8efd381d Author: rsunderbabu Date: 2020-03-06 10:27 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/92cf8efd381d 8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout Summary: Removed timeout=5 from the tests so that default timeout is used Reviewed-by: cjplummer Contributed-by: ramkumar.sunderbabu at oracle.com ! test/jdk/javax/management/loading/MletParserLocaleTest.java ! test/jdk/javax/management/loading/ParserInfiniteLoopTest.java Changeset: 41f79689c039 Author: mbaesken Date: 2020-03-05 13:12 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/41f79689c039 8240603: Windows 32bit compile error after 8238676 Reviewed-by: clanger, dholmes ! test/hotspot/jtreg/runtime/jni/atExit/libatExit.c Changeset: 571b228bf874 Author: mdoerr Date: 2020-03-06 11:04 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/571b228bf874 8239856: [ntintel] asserts about copying unaligned array element Reviewed-by: stuefe, sspitsyn ! src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c Changeset: b009dd349913 Author: iwalulya Date: 2020-03-06 11:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/b009dd349913 8240589: OtherRegionsTable::_num_occupied not updated correctly Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp Changeset: 942c6102590a Author: rkennke Date: 2020-03-06 13:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/942c6102590a 8236981: Remove ShenandoahTraversalUpdateRefsClosure Reviewed-by: shade, rkennke Contributed-by: adityam at microsoft.com ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: cc8382a9118c Author: iwalulya Date: 2020-03-06 14:10 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/cc8382a9118c 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 2b6e1b425f5f Author: rschmelter Date: 2020-03-06 16:19 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/2b6e1b425f5f 8240440: Implement get_safepoint_workers() for parallel GC Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp Changeset: 1c40993361d0 Author: sgehwolf Date: 2020-02-24 19:03 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1c40993361d0 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111 Reviewed-by: mbaesken, bobv ! test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/lib/jdk/test/lib/containers/cgroup/CgroupMetricsTester.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java Changeset: dffc5585fa99 Author: shade Date: 2020-03-06 17:03 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/dffc5585fa99 8240671: Shenandoah: refactor ShenandoahPhaseTimings Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 90c1d2c1f333 Author: mullan Date: 2020-03-06 13:17 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/90c1d2c1f333 8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed" Reviewed-by: xuelei, stsmirno, dcubed ! test/jdk/ProblemList.txt Changeset: d0305db138ee Author: bpb Date: 2020-03-06 10:34 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/d0305db138ee 4617266: (se spec) SelectionKey.OP_READ/OP_WRITE documentation errors Reviewed-by: lancea, alanb, darcy ! src/java.base/share/classes/java/nio/channels/SelectionKey.java Changeset: c81062051951 Author: rriggs Date: 2020-03-06 13:52 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/c81062051951 8239893: Windows handle Leak when starting processes using ProcessBuilder Reviewed-by: bpb, naoto ! src/java.base/windows/classes/java/lang/ProcessImpl.java + test/jdk/java/lang/ProcessBuilder/checkHandles/CheckHandles.java + test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c Changeset: 22e4f0169cab Author: rkennke Date: 2020-03-06 21:51 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/22e4f0169cab 8240315: Shenandoah: Rename ShLBN::get_barrier_strength() Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp Changeset: f79f4f745f98 Author: ccheung Date: 2020-03-06 15:33 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/f79f4f745f98 8232081: Try to link all classes during dynamic CDS dump Summary: During CDS dynamic dump, link all classes loaded by the builtin class loaders in JVM_BeforeHalt() and JavaThread::invoke_shutdown_hooks(). Reviewed-by: iklam, dholmes ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/thread.cpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LinkClassTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/LinkClassApp.java Changeset: ba031902229b Author: kbarrett Date: 2020-03-06 18:42 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/ba031902229b 8240239: Replace ConcurrentGCPhaseManager Summary: Replace ConcurrentGCPhaseManager with ConcurrentGCBreakpoints Reviewed-by: kbarrett, pliden, sangheki Contributed-by: kim.barrett at oracle.com, per.liden at oracle.com ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp ! src/hotspot/share/gc/g1/g1VMOperations.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp + src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp + src/hotspot/share/gc/shared/concurrentGCBreakpoints.hpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp + src/hotspot/share/gc/z/zBreakpoint.cpp + src/hotspot/share/gc/z/zBreakpoint.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp + test/hotspot/jtreg/gc/TestConcurrentGCBreakpoints.java + test/hotspot/jtreg/gc/TestJNIWeak/TestJNIWeak.java + test/hotspot/jtreg/gc/TestJNIWeak/libTestJNIWeak.c - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c ! test/lib/sun/hotspot/WhiteBox.java Changeset: b68736876ab5 Author: mikael Date: 2020-03-06 17:33 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/b68736876ab5 8240535: Add additional linux-aarch64 jib profiles Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 7af6364e1792 Author: jjg Date: 2020-03-06 18:03 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/7af6364e1792 8240137: Support chained use of Content.add Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Entity.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/FixedStringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Script.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java Changeset: cb85119495ba Author: jiefu Date: 2020-03-07 14:42 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/cb85119495ba 8240695: Build is broken when cds is disabled after JDK-8232081 Reviewed-by: iklam ! src/hotspot/share/memory/metaspaceShared.hpp Changeset: ca2dcaf37fad Author: vtewari Date: 2020-03-07 18:35 +0530 URL: https://hg.openjdk.java.net/amber/amber/rev/ca2dcaf37fad 8238579: HttpsURLConnection drops the timeout and hangs forever in read Summary: HttpsURLConnection drops the timeout and hangs forever in read Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java Changeset: 4b80c89e76ca Author: bulasevich Date: 2020-03-07 16:27 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/4b80c89e76ca 8239514: Build for arm-linux-gnueabihf fails with undefined reference read_polling_page Reviewed-by: dsamersoff, dholmes ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp Changeset: e44b68e5bdaf Author: itakiguchi Date: 2020-03-08 15:15 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/e44b68e5bdaf 8239965: XMLEncoder/Test4625418.java fails due to "Error: Cp943 - can't read properly" Summary: Cp943 and x-IBM943 should skip on XMLEncoder/Test4625418.java Reviewed-by: naoto ! test/jdk/ProblemList.txt ! test/jdk/java/beans/XMLEncoder/Test4625418.java Changeset: 2420daa87866 Author: kbarrett Date: 2020-03-08 17:33 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/2420daa87866 8240133: G1DirtyCardQueue destructor has useless flush Summary: Removed useless call to flush. Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: 0fe71e38ecc4 Author: iklam Date: 2020-03-08 15:06 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/0fe71e38ecc4 8240613: InstanceKlass::set_init_state failed with assert(good_state || state == allocated) Reviewed-by: dcubed ! src/hotspot/share/classfile/systemDictionary.cpp Changeset: 13c54fd3bc8c Author: rhalade Date: 2020-03-09 00:45 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/13c54fd3bc8c 8240686: 70 security tests are failing on Windows due to "Fetch artifact failed" Reviewed-by: xuelei ! test/jdk/ProblemList.txt Changeset: 3437fb6311fd Author: kbarrett Date: 2020-03-09 04:06 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/3437fb6311fd 8240722: [BACKOUT] G1DirtyCardQueue destructor has useless flush Summary: Backout JDK-8240133 Reviewed-by: sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: 8d1e70f7f279 Author: roland Date: 2020-03-05 15:56 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8d1e70f7f279 8239335: C2: assert((Value(phase) == t) || (t != TypeInt::CC_GT && t != TypeInt::CC_EQ)) failed: missing Value() optimization Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/subtypenode.cpp + test/hotspot/jtreg/compiler/types/TestIntArraySubTypeOfCloneableDoesnotFold.java Changeset: 598ac6de2237 Author: rkennke Date: 2020-03-09 12:29 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/598ac6de2237 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header Reviewed-by: rkennke Contributed-by: adityam at microsoft.com ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp Changeset: 8a14919d365d Author: kevinw Date: 2020-03-09 12:54 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/8a14919d365d 8240295: hs_err elapsed time in seconds is not accurate enough Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/runtime/os.cpp Changeset: 666e310e158f Author: neugens Date: 2020-03-09 14:57 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/666e310e158f 8240738: nested comment in JVM.java and other minor formatting errors Reviewed-by: egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java Changeset: 0238badf51bc Author: fyang Date: 2020-03-09 22:31 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/0238badf51bc 8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges Reviewed-by: kvn Contributed-by: hedongbo at huawei.com ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestBeautifyLoops.java Changeset: 79371dab85c2 Author: henryjen Date: 2020-03-06 13:48 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/79371dab85c2 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk Reviewed-by: alanb, mchung ! src/java.base/share/native/libjli/args.c ! test/jdk/tools/launcher/ArgFileSyntax.java Changeset: 20023740a683 Author: dfuchs Date: 2020-03-09 17:48 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/20023740a683 8240754: Instrument FlowTest.java to provide more debug traces. Reviewed-by: chegar ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java Changeset: 298b62120b5a Author: naoto Date: 2020-03-09 13:20 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/298b62120b5a 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity Reviewed-by: rriggs, joehw, scolebourne ! src/java.base/share/classes/java/time/zone/ZoneRules.java ! test/jdk/java/time/test/java/time/zone/TestZoneRules.java Changeset: b03adcb5dd5f Author: egahlin Date: 2020-03-09 21:25 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/b03adcb5dd5f 8222000: JFR: Process start event Reviewed-by: mgronlun, rriggs ! src/java.base/share/classes/java/lang/ProcessBuilder.java + src/java.base/share/classes/jdk/internal/event/ProcessStartEvent.java + src/jdk.jfr/share/classes/jdk/jfr/events/ProcessStartEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc ! test/jdk/jdk/jfr/event/metadata/TestDefaultConfigurations.java + test/jdk/jdk/jfr/event/os/TestProcessStart.java ! test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java Changeset: 563d6852da45 Author: egahlin Date: 2020-03-09 21:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/563d6852da45 8239584: EventStream::close should state that stream will be stopped Reviewed-by: mgronlun, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java Changeset: a74b7501917d Author: shade Date: 2020-03-09 22:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a74b7501917d 8240749: Shenandoah: refactor ShenandoahUtils Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: ffa717c6ffee Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ffa717c6ffee 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker Reviewed-by: rkennke - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp Changeset: 7e741a3fc650 Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/7e741a3fc650 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.inline.hpp Changeset: b639fff3fc5a Author: roland Date: 2020-03-10 10:45 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/b639fff3fc5a 8240794: [BACKOUT] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" Reviewed-by: thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/gcm.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/type.hpp - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java Changeset: 7c057af653f9 Author: iwalulya Date: 2020-03-10 10:19 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/7c057af653f9 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp Changeset: b760fca91d75 Author: jjiang Date: 2020-03-10 21:43 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/b760fca91d75 8238740: java/net/httpclient/whitebox/FlowTestDriver.java would not specify a TLS protocol Reviewed-by: dfuchs ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java Changeset: 12b01a07515d Author: mgronlun Date: 2020-03-10 15:44 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/12b01a07515d 8238180: RunThese30M failed "assert(t->jfr_thread_local()->shelved_buffer() == __null) failed: invariant" Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp Changeset: a611125840f0 Author: fyang Date: 2020-03-09 18:21 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/a611125840f0 8240734: ModuleHashes attribute not reproducible between builds Reviewed-by: alanb Contributed-by: hedongbo at huawei.com ! src/java.base/share/classes/jdk/internal/module/ModuleHashes.java ! src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java Changeset: 5474f3ecded4 Author: roland Date: 2020-03-09 09:42 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/5474f3ecded4 8240195: some jaotc failures of fastdebug build with specific flags Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/subtypenode.cpp + test/hotspot/jtreg/compiler/types/TestSubTypeOfAsbtractClassWrongResult.java Changeset: 478dbbe9b422 Author: egahlin Date: 2020-03-10 18:39 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/478dbbe9b422 8240778: JFR: Create timer task lazily Reviewed-by: mgronlun, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java Changeset: eab1d242c9f6 Author: vlivanov Date: 2020-03-10 20:51 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/eab1d242c9f6 8238681: Make -XX:UseSSE flag x86-specific Reviewed-by: dholmes, kvn ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/sparc/vm_version_sparc.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/c1/Test6579789.java ! test/hotspot/jtreg/compiler/c1/Test6855215.java Changeset: e673324c4045 Author: vlivanov Date: 2020-03-10 20:51 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/e673324c4045 8239008: C2: Simplify Replicate support for sub-word types on x86 Reviewed-by: kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/x86.ad Changeset: 3f26298f486f Author: vlivanov Date: 2020-03-10 20:51 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/3f26298f486f 8239009: C2: Don't use PSHUF to load scalars from memory on x86 Reviewed-by: kvn, dlong ! src/hotspot/cpu/x86/x86.ad Changeset: 8c0b7b88b646 Author: minqi Date: 2020-03-10 11:52 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/8c0b7b88b646 8240691: ClhsdbCDSJstackPrintAll incorrectly thinks CDS is in use Summary: Fix by checking "UseSharedSpaces = false" for CDS enabled. Reviewed-by: iklam ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSJstackPrintAll.java Changeset: 81e8e9394197 Author: dnsimon Date: 2020-03-10 21:48 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/81e8e9394197 8240610: [JVMCI] Export VMVersion::_has_intel_jcc_erratum to JVMCI compiler Reviewed-by: kvn, thartmann Contributed-by: Yudi Zheng ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: a67aa7e073d8 Author: minqi Date: 2020-03-10 14:37 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/a67aa7e073d8 8240840: Rollback whitebox.cpp in push 8240691 Summary: whitebox.cpp should not change in 8240691, which is accidentally included. Reviewed-by: iklam, ccheung ! src/hotspot/share/prims/whitebox.cpp Changeset: 18d4d0cc3372 Author: kvn Date: 2020-03-10 14:39 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/18d4d0cc3372 8240830: [BACKOUT] 8240195: some jaotc failures of fastdebug build with specific flags Reviewed-by: dcubed ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/subtypenode.cpp - test/hotspot/jtreg/compiler/types/TestSubTypeOfAsbtractClassWrongResult.java Changeset: 301f91ab1636 Author: jjg Date: 2020-03-10 14:46 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/301f91ab1636 8240697: convert builders to high-level Content blocks Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/BodyContents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TableHeader.java Changeset: 82b0b99acdbb Author: asotona Date: 2020-03-10 17:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/82b0b99acdbb 8235216: typo in test filename Summary: renamed MutliReleaseModuleInfoTest.java to MultiReleaseModuleInfoTest.java Reviewed-by: jjg + test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseModuleInfoTest.java - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java Changeset: faa4916a3379 Author: cito Date: 2020-03-07 23:08 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/faa4916a3379 8222489: jcmd VM.system_properties gives unusable paths on Windows Reviewed-by: sspitsyn, ysuenaga ! src/java.base/share/classes/jdk/internal/vm/VMSupport.java + test/jdk/sun/tools/jcmd/TestVM.java Changeset: 8c78138be591 Author: weijun Date: 2020-03-11 10:33 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/8c78138be591 8239928: ec/ECDSAJavaVerify.java failed due to timeout Reviewed-by: valeriep ! test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: 590ac5a59078 Author: ysuenaga Date: 2020-03-11 13:14 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/590ac5a59078 8240725: Some functions might not work with CJK character Reviewed-by: naoto ! src/java.base/share/native/libzip/zip_util.c ! src/java.base/windows/native/libjava/canonicalize_md.c ! src/java.base/windows/native/libjli/java_md.c ! src/jdk.incubator.jpackage/windows/native/libapplauncher/WindowsPlatform.cpp Changeset: 8c5697ed51b2 Author: ihse Date: 2020-03-11 08:34 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8c5697ed51b2 8240820: Replace AC_ARG_ENABLE with UTIL_ARG_ENABLE Reviewed-by: erikj ! make/autoconf/build-performance.m4 ! make/autoconf/flags-cflags.m4 ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/lib-ffi.m4 ! make/autoconf/platform.m4 ! make/autoconf/util.m4 ! test/make/autoconf/test.m4 Changeset: 1fdd52277cfb Author: ehelin Date: 2020-03-10 16:58 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1fdd52277cfb 8237566: FindTests.gmk should only include existing TEST.ROOT files Reviewed-by: erikj ! make/common/FindTests.gmk Changeset: 719a3cd91e92 Author: stefank Date: 2020-03-04 15:50 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/719a3cd91e92 8240530: CheckUnhandledOops breaks BacktraceBuilder::set_has_hidden_top_frame Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/javaClasses.cpp Changeset: bb44e0d9fe1f Author: stefank Date: 2020-03-04 15:50 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/bb44e0d9fe1f 8240529: CheckUnhandledOops breaks NULL check in Modules::define_module Reviewed-by: coleenp, lfoltan, hseigel ! src/hotspot/share/classfile/modules.cpp Changeset: 12eb1e2087d2 Author: stefank Date: 2020-03-04 18:08 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/12eb1e2087d2 8240532: heap inspection prints trailing @ after name of module without version Reviewed-by: lfoltan ! src/hotspot/share/memory/heapInspection.cpp ! test/hotspot/jtreg/serviceability/dcmd/gc/ClassHistogramTest.java Changeset: e50512f91026 Author: aph Date: 2020-03-10 10:49 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/e50512f91026 8240615: is_power_of_2() has Undefined Behaviour and is inconsistent Reviewed-by: jrose, redestad ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/utilities/powerOfTwo.hpp ! test/hotspot/gtest/utilities/test_powerOfTwo.cpp Changeset: 65f30e209890 Author: clanger Date: 2020-03-11 13:50 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/65f30e209890 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java Reviewed-by: clanger, vtewari Contributed-by: vipinsharma85 at gmail.com ! test/jdk/java/lang/Boolean/GetBoolean.java ! test/jdk/java/lang/Boolean/MakeBooleanComparable.java ! test/jdk/java/lang/Boolean/ParseBoolean.java Changeset: 6cac1afd2a63 Author: shade Date: 2020-03-11 14:17 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6cac1afd2a63 8240868: Shenandoah: remove CM-with-UR piggybacking cycles Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java Changeset: d0ff3ee1bf40 Author: aph Date: 2020-03-11 12:38 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/d0ff3ee1bf40 8240829: Use a fast O(1) algorithm for exact_log2 Reviewed-by: jrose, redestad ! src/hotspot/share/utilities/powerOfTwo.hpp ! test/hotspot/gtest/utilities/test_powerOfTwo.cpp Changeset: f9893c227e12 Author: aph Date: 2020-03-11 15:02 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f9893c227e12 Merge Changeset: eb934f0048de Author: bae Date: 2020-03-11 19:14 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/eb934f0048de 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException Reviewed-by: xuelei Contributed-by: alexey at azul.com ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! test/jdk/sun/security/ssl/SSLSocketImpl/ClientTimeout.java ! test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java Changeset: d9dd1627e074 Author: lancea Date: 2020-03-11 12:30 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/d9dd1627e074 8230117: Remove unused JAR tool classes Reviewed-by: lancea, clanger Contributed-by: Adam Sotona - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java Changeset: 3a3ce5f3e2f7 Author: prappo Date: 2020-03-11 17:09 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/3a3ce5f3e2f7 8239487: Better links generation for system properties found in HTML files 8239485: Define behavior of the System Properties page when no system properties are available Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItem.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItems.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/DocFileElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/overview.html + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/A.java + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/doc-files/WithEmptyTitle.html + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/doc-files/WithTitle.html + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/doc-files/WithoutTitle.html + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg2/B.java + test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src2/pkg1/A.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 055991789807 Author: sspitsyn Date: 2020-03-11 20:28 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/055991789807 8240881: [BACKOUT] 8222489 jcmd VM.system_properties gives unusable paths on Windows Summary: Undo the 8222489 changeset Reviewed-by: dcubed, iklam ! src/java.base/share/classes/jdk/internal/vm/VMSupport.java - test/jdk/sun/tools/jcmd/TestVM.java Changeset: d462f05faa2d Author: amenkov Date: 2020-03-11 13:39 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/d462f05faa2d 8240340: java/lang/management/ThreadMXBean/Locks.java is buggy Reviewed-by: dholmes, sspitsyn ! test/jdk/java/lang/management/ThreadMXBean/Locks.java ! test/lib/jdk/test/lib/LockFreeLogger.java Changeset: 1d6ceb13e142 Author: ihse Date: 2020-03-11 22:25 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1d6ceb13e142 8240866: Typo in JDK-8240820 messes up configure --help Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 ! make/autoconf/hotspot.m4 Changeset: 5f690d6174b5 Author: jjg Date: 2020-03-11 15:46 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/5f690d6174b5 8240138: Cleanup HtmlTree Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTag.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java Changeset: a6c70ccaa775 Author: ysuenaga Date: 2020-03-12 09:23 +0900 URL: https://hg.openjdk.java.net/amber/amber/rev/a6c70ccaa775 8234624: jstack mixed mode should refer DWARF Reviewed-by: sspitsyn, kevinw + src/jdk.hotspot.agent/linux/native/libsaproc/DwarfParser.cpp ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp + src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp + src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.hpp ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.h ! src/jdk.hotspot.agent/linux/native/libsaproc/salibelf.c ! src/jdk.hotspot.agent/linux/native/libsaproc/salibelf.h ! src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/DwarfParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java Changeset: e103a5398b54 Author: jwilhelm Date: 2020-03-12 03:10 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e103a5398b54 Added tag jdk-15+14 for changeset 1d6ceb13e142 ! .hgtags Changeset: 91f95b517b0c Author: iklam Date: 2020-03-11 21:37 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/91f95b517b0c 8240548: [TESTBUG] CDS NoClassToArchive.java fails with Graal Reviewed-by: dholmes, mchung ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NoClassToArchive.java Changeset: 4ee517d2e206 Author: shade Date: 2020-03-12 06:47 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4ee517d2e206 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah Reviewed-by: shade Contributed-by: Kelvin Nilsen ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/gc/logging/TestMetaSpaceLog.java Changeset: a744cb5d03d6 Author: weijun Date: 2020-03-12 18:21 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/a744cb5d03d6 8240261: Use make/templates/gpl-cp-header in FieldGen.java Reviewed-by: erikj ! make/gensrc/Gensrc-java.base.gmk ! make/jdk/src/classes/build/tools/intpoly/FieldGen.java - make/jdk/src/classes/build/tools/intpoly/header.txt + make/jdk/src/classes/build/tools/util/Header.java Changeset: ecc59c31cb10 Author: rrich Date: 2020-03-12 11:51 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ecc59c31cb10 8234146: compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC Reviewed-by: vlivanov, thartmann ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/jsr292/ContinuousCallSiteTargetChange.java Changeset: 4923c49ba7b5 Author: redestad Date: 2020-03-12 13:07 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4923c49ba7b5 8240772: x86_64: Pre-generate Assembler::popa, pusha and vzeroupper Reviewed-by: iklam, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp Changeset: fec7d7b39038 Author: redestad Date: 2020-03-05 16:07 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/fec7d7b39038 8240669: Devirtualize Relocation::type Reviewed-by: rbackman, thartmann ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: 2d4a9ff1de2e Author: dnsimon Date: 2020-03-12 13:20 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/2d4a9ff1de2e 8240831: [JVMCI] Export missing vmStructs entries used by JVMCI compilers Reviewed-by: kvn, thartmann Contributed-by: Yudi Zheng ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 724e0cf52991 Author: zgu Date: 2020-03-12 09:25 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/724e0cf52991 8240915: Shenandoah: Remove unused fields in init mark tasks Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: a9a78d821f37 Author: vlivanov Date: 2020-03-12 16:42 +0300 URL: https://hg.openjdk.java.net/amber/amber/rev/a9a78d821f37 8238696: x86: Enumerate all detected CPU features in VM_Version feature string Reviewed-by: dholmes, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad + test/jdk/lib/testlibrary/CPUInfoTest.java Changeset: d527da8f8f9b Author: sgehwolf Date: 2020-02-25 12:17 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d527da8f8f9b 8239785: Cgroups: Incorrect detection logic on old systems in hotspot Summary: Return NULL subsystem if no cgroup controllers are mounted. Reviewed-by: bobv, mbaesken ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/prims/whitebox.hpp + test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 7898edac8a27 Author: naoto Date: 2020-03-12 08:31 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/7898edac8a27 8216332: Grapheme regex does not work with emoji sequences Reviewed-by: rriggs ! src/java.base/share/classes/java/util/regex/Grapheme.java + test/jdk/java/util/regex/GraphemeTestCases.txt ! test/jdk/java/util/regex/RegExTest.java Changeset: 910e8900f11d Author: rriggs Date: 2020-03-12 11:54 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/910e8900f11d 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent." Reviewed-by: dfuchs ! test/jdk/java/lang/ProcessBuilder/checkHandles/CheckHandles.java Changeset: e713e8a312ea Author: rriggs Date: 2020-03-12 11:57 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/e713e8a312ea 8240957: Clarify BadAttributeValueExpException readObject method Reviewed-by: bpb ! src/java.management/share/classes/javax/management/BadAttributeValueExpException.java Changeset: fa70160bcf72 Author: minqi Date: 2020-03-12 09:07 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/fa70160bcf72 8240563: [TESTBUG] WB_IsCDSIncludedInVmBuild should support uncompressed oops/klasses Summary: With 8232069, CDS works with uncompressed oops/kalsses, detecting CDS code no longer bases on the two flags. Reviewed-by: iklam ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java ! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java Changeset: c0f672668596 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c0f672668596 8240872: Shenandoah: Avoid updating new regions from start of evacuation Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Changeset: cc0ffb1d0458 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/cc0ffb1d0458 8240873: Shenandoah: Short-cut arraycopy barriers Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 67a2ce1f3a0a Author: zgu Date: 2020-03-12 13:08 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/67a2ce1f3a0a 8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: be3aeb6e766d Author: pconcannon Date: 2020-03-12 17:08 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/be3aeb6e766d 8239355: (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS) Summary: Updates DatagramChannel so that the SO_SNDBUF is set to a minimum value of 65527 for IPv6 sockets and 65507 for IPv4 sockets on macOS. Reviewed-by: alanb, dfuchs ! src/java.base/unix/native/libnio/ch/Net.c ! test/jdk/java/net/IPSupport/MinimumPermissions.policy + test/jdk/java/nio/channels/DatagramChannel/MinSendBufferSize.java ! test/lib/jdk/test/lib/net/IPSupport.java Changeset: f2a8072492df Author: pconcannon Date: 2020-03-12 17:20 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f2a8072492df Merge Changeset: 61f6c19d1a56 Author: shade Date: 2020-03-12 18:50 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/61f6c19d1a56 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: 29f4b46a1680 Author: dfuchs Date: 2020-03-12 18:31 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/29f4b46a1680 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root" Summary: The solaris specific code is changed to use the fallback mechanism if the DLPI interface returns an error indicating that the operation is unsupported. In addition, NetworkInterface::getHardwareAddress is changed to always return null for the loopback interface. Reviewed-by: alanb ! src/java.base/share/classes/java/net/NetworkInterface.java ! src/java.base/unix/native/libnet/NetworkInterface.c + test/jdk/java/net/NetworkInterface/NullMacAddress.java Changeset: 222127a06550 Author: ihse Date: 2020-03-12 19:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/222127a06550 8240947: Change conflicting JVM features from warning to error Reviewed-by: erikj ! make/autoconf/jvm-features.m4 Changeset: 5edc259054ae Author: ihse Date: 2020-03-12 19:42 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/5edc259054ae 8149110: Introduce DISABLED_WARNINGS for Java compilation Reviewed-by: erikj ! make/CompileDemos.gmk ! make/CompileInterimLangtools.gmk ! make/CompileInterimRmic.gmk ! make/CompileJavaModules.gmk ! make/CompileModuleTools.gmk ! make/CompileToolsJdk.gmk ! make/common/JavaCompilation.gmk ! make/common/SetupJavaCompilers.gmk ! make/hotspot/gensrc/GensrcJfr.gmk ! make/hotspot/gensrc/GensrcJvmti.gmk ! make/hotspot/ide/CreateVSProject.gmk ! make/test/BuildFailureHandler.gmk ! make/test/BuildMicrobenchmark.gmk ! make/test/JtregGraalUnit.gmk Changeset: e594b41c45c4 Author: ihse Date: 2020-03-12 19:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e594b41c45c4 8240950: Missing AC_SUBST after JDK-82408 Reviewed-by: erikj ! make/autoconf/build-performance.m4 Changeset: 1ca940d73efc Author: mchung Date: 2020-03-12 11:54 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/1ca940d73efc 8228336: Refactor native library loading implementation Reviewed-by: alanb, dholmes ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/nativeLookup.cpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java + src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Runtime.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java + src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java + src/java.base/share/classes/jdk/internal/loader/NativeLibrary.java ! src/java.base/share/native/libjava/ClassLoader.c + src/java.base/share/native/libjava/NativeLibraries.c - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java + src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java + src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java ! test/jdk/java/lang/ClassLoader/LibraryPathProperty.java Changeset: e287fc5b9e86 Author: mchung Date: 2020-03-12 11:56 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/e287fc5b9e86 8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL Reviewed-by: chegar, rriggs ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 4253bf176649 Author: erikj Date: 2020-03-12 12:55 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/4253bf176649 8240972: macOS codesign fail on macOS 10.13.5 or older Reviewed-by: erikj, ihse Contributed-by: junyuan.zheng at microsoft.com ! make/autoconf/basic_tools.m4 Changeset: b2b9f856b71a Author: jjg Date: 2020-03-12 13:56 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/b2b9f856b71a 8240971: Fix CSS styles in some doc comments Reviewed-by: mchung ! src/java.base/share/classes/module-info.java ! src/java.management.rmi/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.jconsole/share/classes/module-info.java Changeset: 66c7a7990f69 Author: jjg Date: 2020-03-12 14:14 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/66c7a7990f69 8240555: Using env of JAVA_TOOL_OPTIONS and _JAVA_OPTIONS breaks QuietOption.java test Reviewed-by: shurailine, prappo ! test/langtools/jdk/javadoc/tool/QuietOption.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:05:01 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:05:01 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131605.02DG512B016944@aojmv0008.oracle.com> Changeset: b237d5752f53 Author: mcimadamore Date: 2020-03-13 16:04 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/b237d5752f53 Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java ! src/java.base/share/classes/module-info.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:05:24 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:05:24 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131605.02DG5PI7017253@aojmv0008.oracle.com> Changeset: 247eaa3954db Author: mcimadamore Date: 2020-03-13 16:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/247eaa3954db Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt ! src/hotspot/share/classfile/vmSymbols.hpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/prims/jvm.cpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:08:06 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:08:06 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131608.02DG86sP022834@aojmv0008.oracle.com> Changeset: 8324b27a027f Author: mcimadamore Date: 2020-03-13 16:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/8324b27a027f Automatic merge with default ! make/CompileInterimLangtools.gmk - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java ! src/java.base/share/classes/module-info.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From jan.lahoda at oracle.com Fri Mar 13 15:59:36 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 13 Mar 2020 15:59:36 +0000 Subject: hg: amber/amber: Various improvements related to deconstruction patterns. Message-ID: <202003131559.02DFxaZb015034@aojmv0008.oracle.com> Changeset: fb351b9d0440 Author: jlahoda Date: 2020-03-13 16:58 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/fb351b9d0440 Various improvements related to deconstruction patterns. ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out + test/langtools/tools/javac/patterns/PrettyTest.java ! test/langtools/tools/javac/patterns/SimpleDeconstructionPattern.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:05:47 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:05:47 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131605.02DG5l6v017610@aojmv0008.oracle.com> Changeset: a3386eb783d2 Author: mcimadamore Date: 2020-03-13 16:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/a3386eb783d2 Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:06:11 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:06:11 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131606.02DG6BVv018647@aojmv0008.oracle.com> Changeset: a4fd33a18776 Author: mcimadamore Date: 2020-03-13 16:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/a4fd33a18776 Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:06:33 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:06:33 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131606.02DG6YbA019056@aojmv0008.oracle.com> Changeset: 1e8e98f1dc99 Author: mcimadamore Date: 2020-03-13 16:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/1e8e98f1dc99 Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:06:56 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:06:56 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131606.02DG6vYG019880@aojmv0008.oracle.com> Changeset: f9cb34731e95 Author: mcimadamore Date: 2020-03-13 16:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f9cb34731e95 Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:07:19 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:07:19 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131607.02DG7JlG020856@aojmv0008.oracle.com> Changeset: 7563c266b89f Author: mcimadamore Date: 2020-03-13 16:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/7563c266b89f Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:07:43 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:07:43 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202003131607.02DG7h1f022242@aojmv0008.oracle.com> Changeset: 96dc633cd9e1 Author: mcimadamore Date: 2020-03-13 16:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/96dc633cd9e1 Automatic merge with default - make/jdk/src/classes/build/tools/intpoly/header.txt - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java From maurizio.cimadamore at oracle.com Fri Mar 13 16:08:30 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Mar 2020 16:08:30 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202003131608.02DG8VJ7023355@aojmv0008.oracle.com> Changeset: 7347cc51c794 Author: mcimadamore Date: 2020-03-13 16:08 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/7347cc51c794 Automatic merge with sealed-types ! .hgtags ! make/autoconf/flags-cflags.m4 - make/jdk/src/classes/build/tools/intpoly/header.txt ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp - src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/vmOperations.hpp - src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/net/NetworkInterface.java ! src/java.base/share/classes/module-info.java - src/java.base/unix/classes/java/lang/ClassLoaderHelper.java ! src/java.base/unix/native/libnet/NetworkInterface.c - src/java.base/windows/classes/java/lang/ClassLoaderHelper.java - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java - test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java - test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c ! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java ! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NoClassToArchive.java ! test/jdk/ProblemList.txt - test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java From jan.lahoda at oracle.com Mon Mar 16 16:08:27 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 16 Mar 2020 16:08:27 +0000 Subject: hg: amber/amber: Patterns stage 2: more cleanup Message-ID: <202003161608.02GG8RRA029466@aojmv0008.oracle.com> Changeset: e04704954553 Author: jlahoda Date: 2020-03-16 17:08 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e04704954553 Patterns stage 2: more cleanup ! src/jdk.compiler/share/classes/com/sun/source/tree/DeconstructionPatternTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + test/langtools/tools/javac/diags/examples/DeconstructionPatternOnlyRecords.java ! test/langtools/tools/javac/patterns/BindingsTest1.java ! test/langtools/tools/javac/patterns/PrettyTest.java ! test/langtools/tools/javac/patterns/SimpleDeconstructionPattern.java + test/langtools/tools/javac/patterns/SimpleDeconstructionPatternNoPreview.out From jan.lahoda at oracle.com Tue Mar 17 15:00:34 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 17 Mar 2020 15:00:34 +0000 Subject: hg: amber/amber: Adding error when the are too little or too many deconstruction parameters. Message-ID: <202003171500.02HF0YlB025239@aojmv0008.oracle.com> Changeset: cbb1252ab121 Author: jlahoda Date: 2020-03-17 15:58 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/cbb1252ab121 Adding error when the are too little or too many deconstruction parameters. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/diags/examples/IncorrectNumberOfNestedPatterns.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out From jan.lahoda at oracle.com Wed Mar 18 08:55:11 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Mar 2020 09:55:11 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. Message-ID: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Hi, I would like to ask for a review for a patch that implements the deconstruction patterns, as described in JEP 375: https://bugs.openjdk.java.net/browse/JDK-8235186 The current specification draft is here: http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html For this phase, the proposal is for javac to desugar the deconstruction patterns using record accessors. The CSR for this change is being written here: https://bugs.openjdk.java.net/browse/JDK-8240999 The proposed patch: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 Any feedback is welcome! Thanks, Jan From forax at univ-mlv.fr Wed Mar 18 09:57:19 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 18 Mar 2020 10:57:19 +0100 (CET) Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: <1421610973.1641517.1584525439096.JavaMail.zimbra@u-pem.fr> Hi Jan, in the CSR part, you don't talk about the drawbacks of using a deconstruction pattern, the syntax of a deconstruction pattern forces you to declare the number of record components you have, so adding (by example) one record component to a record will makes the code of instanceof to not compile anymore. Let say you have record Point(int x, int y); with the current instanceof one can write if (o instanceof Point p) { System.out.println(p.x() + " " + p.y()); } with a deconstruction pattern, you will write if (o instanceof Point(int x, int y)) { System.out.println(x + " " + y); } now if you change Point to record Point(int x, int y, int z); the first code still compile but the second doesn't not anymore (but it still works at runtime in case of separate compilation). It's not a big deal, it doesn't make the deconstruction pattern useless at all but I think it's something developers should be aware of. regards, R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "compiler-dev" > Cc: "amber-dev" > Envoy?: Mercredi 18 Mars 2020 09:55:11 > Objet: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. > Hi, > > I would like to ask for a review for a patch that implements the > deconstruction patterns, as described in JEP 375: > https://bugs.openjdk.java.net/browse/JDK-8235186 > > The current specification draft is here: > http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html > > For this phase, the proposal is for javac to desugar the deconstruction > patterns using record accessors. > > The CSR for this change is being written here: > https://bugs.openjdk.java.net/browse/JDK-8240999 > > The proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 > > Any feedback is welcome! > > Thanks, > Jan From jan.lahoda at oracle.com Wed Mar 18 15:48:10 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Mar 2020 16:48:10 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <1421610973.1641517.1584525439096.JavaMail.zimbra@u-pem.fr> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <1421610973.1641517.1584525439096.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks Remi, I tried to update the CSR with this warning. Thanks, Jan On 18. 03. 20 10:57, Remi Forax wrote: > Hi Jan, > in the CSR part, > you don't talk about the drawbacks of using a deconstruction pattern, the syntax of a deconstruction pattern forces you to declare the number of record components you have, so adding (by example) one record component to a record will makes the code of instanceof to not compile anymore. > > Let say you have > record Point(int x, int y); > with the current instanceof one can write > if (o instanceof Point p) { > System.out.println(p.x() + " " + p.y()); > } > with a deconstruction pattern, you will write > if (o instanceof Point(int x, int y)) { > System.out.println(x + " " + y); > } > > now if you change Point to > record Point(int x, int y, int z); > the first code still compile but the second doesn't not anymore (but it still works at runtime in case of separate compilation). > > It's not a big deal, it doesn't make the deconstruction pattern useless at all but I think it's something developers should be aware of. > > regards, > R?mi > > ----- Mail original ----- >> De: "jan lahoda" >> ?: "compiler-dev" >> Cc: "amber-dev" >> Envoy?: Mercredi 18 Mars 2020 09:55:11 >> Objet: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. > >> Hi, >> >> I would like to ask for a review for a patch that implements the >> deconstruction patterns, as described in JEP 375: >> https://bugs.openjdk.java.net/browse/JDK-8235186 >> >> The current specification draft is here: >> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >> >> For this phase, the proposal is for javac to desugar the deconstruction >> patterns using record accessors. >> >> The CSR for this change is being written here: >> https://bugs.openjdk.java.net/browse/JDK-8240999 >> >> The proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >> >> Any feedback is welcome! >> >> Thanks, >> Jan From vicente.romero at oracle.com Wed Mar 18 17:29:55 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Mar 2020 13:29:55 -0400 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> Hi Jan, Shouldn't this patch also modify some of the visitors at javax.lang.model? Thanks, Vicente On 3/18/20 4:55 AM, Jan Lahoda wrote: > Hi, > > I would like to ask for a review for a patch that implements the > deconstruction patterns, as described in JEP 375: > https://bugs.openjdk.java.net/browse/JDK-8235186 > > The current specification draft is here: > http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html > > > For this phase, the proposal is for javac to desugar the > deconstruction patterns using record accessors. > > The CSR for this change is being written here: > https://bugs.openjdk.java.net/browse/JDK-8240999 > > The proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 > > Any feedback is welcome! > > Thanks, > ??? Jan From jan.lahoda at oracle.com Thu Mar 19 10:42:32 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Mar 2020 11:42:32 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> Message-ID: <0f62be75-d4fe-ac80-5c99-cdb89a019e9a@oracle.com> Hi Vicente, On 18. 03. 20 18:29, Vicente Romero wrote: > Hi Jan, > > Shouldn't this patch also modify some of the visitors at javax.lang.model? With the pattern matching for instanceof in JDK14, we have added ElementKind.BINDING_VARIABLE, and the deconstruction patterns are using that as well. Otherwise, the deconstruction patterns shouldn't (I hope) affect declarations modeled by javax.lang.model? I.e. this only adds a new form of patterns, which are only specific to expressions, which are not modeled by javax.lang.model. Updates to the Trees API are part of the patch. Thanks, Jan > > Thanks, > Vicente > > On 3/18/20 4:55 AM, Jan Lahoda wrote: >> Hi, >> >> I would like to ask for a review for a patch that implements the >> deconstruction patterns, as described in JEP 375: >> https://bugs.openjdk.java.net/browse/JDK-8235186 >> >> The current specification draft is here: >> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >> >> >> For this phase, the proposal is for javac to desugar the >> deconstruction patterns using record accessors. >> >> The CSR for this change is being written here: >> https://bugs.openjdk.java.net/browse/JDK-8240999 >> >> The proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >> >> Any feedback is welcome! >> >> Thanks, >> ??? Jan > From jan.lahoda at oracle.com Thu Mar 19 10:35:23 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Thu, 19 Mar 2020 10:35:23 +0000 Subject: hg: amber/amber: Fixing owners of synthetic pattern-related symbols. Message-ID: <202003191035.02JAZORh018529@aojmv0008.oracle.com> Changeset: 40f48da2c792 Author: jlahoda Date: 2020-03-19 11:34 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/40f48da2c792 Fixing owners of synthetic pattern-related symbols. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java From vicente.romero at oracle.com Thu Mar 19 14:25:38 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Mar 2020 10:25:38 -0400 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <0f62be75-d4fe-ac80-5c99-cdb89a019e9a@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> <0f62be75-d4fe-ac80-5c99-cdb89a019e9a@oracle.com> Message-ID: <263b03e7-0f2e-38a8-4eda-164de5fdd487@oracle.com> On 3/19/20 6:42 AM, Jan Lahoda wrote: > Hi Vicente, > > On 18. 03. 20 18:29, Vicente Romero wrote: >> Hi Jan, >> >> Shouldn't this patch also modify some of the visitors at >> javax.lang.model? > > With the pattern matching for instanceof in JDK14, we have added > ElementKind.BINDING_VARIABLE, and the deconstruction patterns are > using that as well. Otherwise, the deconstruction patterns shouldn't > (I hope) affect declarations modeled by javax.lang.model? I.e. this > only adds a new form of patterns, which are only specific to > expressions, which are not modeled by javax.lang.model. Updates to the > Trees API are part of the patch. ah ok thanks for the clarification, > > Thanks, > ??? Jan Vicente > >> >> Thanks, >> Vicente >> >> On 3/18/20 4:55 AM, Jan Lahoda wrote: >>> Hi, >>> >>> I would like to ask for a review for a patch that implements the >>> deconstruction patterns, as described in JEP 375: >>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>> >>> The current specification draft is here: >>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>> >>> >>> For this phase, the proposal is for javac to desugar the >>> deconstruction patterns using record accessors. >>> >>> The CSR for this change is being written here: >>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>> >>> The proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ??? Jan >> From jan.lahoda at oracle.com Thu Mar 19 15:49:33 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Thu, 19 Mar 2020 15:49:33 +0000 Subject: hg: amber/amber: Correcting deduplication related to deconstruction patterns. Message-ID: <202003191549.02JFnXcx014903@aojmv0008.oracle.com> Changeset: 074d2813de89 Author: jlahoda Date: 2020-03-19 16:22 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/074d2813de89 Correcting deduplication related to deconstruction patterns. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java ! test/langtools/tools/javac/lambda/deduplication/Deduplication.java ! test/langtools/tools/javac/lambda/deduplication/DeduplicationTest.java From jan.lahoda at oracle.com Thu Mar 19 17:25:27 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Mar 2020 18:25:27 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: Hi, Turned out the patch had two bugs - one related to the owners of the temporary variables created, which then broke type annotations; and another that broken de-duplication. I am deeply sorry for that. An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ A delta from previous round: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ I am sorry for any inconvenience. Jan On 18. 03. 20 9:55, Jan Lahoda wrote: > Hi, > > I would like to ask for a review for a patch that implements the > deconstruction patterns, as described in JEP 375: > https://bugs.openjdk.java.net/browse/JDK-8235186 > > The current specification draft is here: > http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html > > > For this phase, the proposal is for javac to desugar the deconstruction > patterns using record accessors. > > The CSR for this change is being written here: > https://bugs.openjdk.java.net/browse/JDK-8240999 > > The proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 > > Any feedback is welcome! > > Thanks, > ??? Jan From forax at univ-mlv.fr Sat Mar 21 18:00:04 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 21 Mar 2020 19:00:04 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: Message-ID: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> Hi Luke, wrong mailing list, record being a preview feature, the right mailing list is amber-dev at openjdk.java.net. (please remove jdk-dev if you reply) ----- Mail original ----- > De: "Luke Hutchison" > ?: "jdk-dev" > Envoy?: Samedi 21 Mars 2020 18:40:41 > Objet: JDK 14 record type representation in classfile format? > How are JDK 14 record types encoded in the classfile format? There is an > 8-byte class attribute named "Record", but the format of this attribute is > not documented in the JDK 14 classfile format specification (presumably > because this feature is still in preview). if you to go at https://docs.oracle.com/javase/specs/ there is a link just below the JVM spec about record because as you said, it's a preview feature https://docs.oracle.com/javase/specs/jvms/se14/preview/specs/records-jvms.html and yes, there is a Record attribute see section 4.7.30. > > Also, records have an "InnerClasses" class attribute, with an inner class > name of "java.lang.invoke.MethodHandles$Lookup" and an outer class name of > "java.lang.invoke.MethodHandles". Normally the outer class name matches the > class whose classfile the attribute is contained in. Why is this inner > class attribute there, and why does the outer class name not match the name > of the record? This look like a bug to me. regards, R?mi From forax at univ-mlv.fr Sat Mar 21 18:39:49 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 21 Mar 2020 19:39:49 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> Message-ID: <901836045.1747112.1584815989462.JavaMail.zimbra@u-pem.fr> > De: "Luke Hutchison" > ?: "Remi Forax" > Cc: "amber-dev" > Envoy?: Samedi 21 Mars 2020 19:13:51 > Objet: Re: JDK 14 record type representation in classfile format? > Sorry for posting to the wrong list. not a big deal :) > On Sat, Mar 21, 2020 at 12:00 PM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> there is a link just below the JVM spec about record because as you said, it's a >> preview feature >> [ https://docs.oracle.com/javase/specs/jvms/se14/preview/specs/records-jvms.html >> | >> https://docs.oracle.com/javase/specs/jvms/se14/preview/specs/records-jvms.html >> ] > Thanks for the link. Records still define private fields. so you can migrate your immutable classes to a record in a backward compatible way > Is there any reason to believe that the private fields listed in a record's > classfile will not always have an exact 1:1 correspondence to > record_component_info entries? i.e. is the information (names, types, arity, > etc.) always exactly equivalent between both places ? The JLS 8.10.3 [1] specifies that there is a 1:1 mapping between a record component, a field and an accessor method. regards, R?mi [1] https://docs.oracle.com/javase/specs/jls/se14/preview/specs/records-jls.html#jls-8.10.3 From forax at univ-mlv.fr Sat Mar 21 20:01:57 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 21 Mar 2020 21:01:57 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> Message-ID: <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Remi Forax" > ?: "Luke Hutchison" > Cc: "jdk-dev" , "amber-dev" > Envoy?: Samedi 21 Mars 2020 19:00:04 > Objet: Re: JDK 14 record type representation in classfile format? [...] >> >> Also, records have an "InnerClasses" class attribute, with an inner class >> name of "java.lang.invoke.MethodHandles$Lookup" and an outer class name of >> "java.lang.invoke.MethodHandles". Normally the outer class name matches the >> class whose classfile the attribute is contained in. Why is this inner >> class attribute there, and why does the outer class name not match the name >> of the record? > > This look like a bug to me. I've created https://bugs.openjdk.java.net/browse/JDK-8241398 to track that. cheers, R?mi From vicente.romero at oracle.com Sat Mar 21 20:19:41 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 21 Mar 2020 16:19:41 -0400 Subject: JDK 14 record type representation in classfile format? In-Reply-To: <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> Message-ID: I don't think that this is a bug. Records are using indy to invoke bootstrap methods that implement: toString, equals and hashCode. The first parameter of every bootstrap method is: java/lang/invoke/MethodHandles$Lookup which is an inner class and thus requires a dedicated InnerClasses attribute. You can reproduce a very similar pattern with any code that uses bootstrap methods like: class StringTest { ??? String m(String s) { ??????? return s + ""; ??? } } Thanks, Vicente On 3/21/20 4:01 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Remi Forax" >> ?: "Luke Hutchison" >> Cc: "jdk-dev" , "amber-dev" >> Envoy?: Samedi 21 Mars 2020 19:00:04 >> Objet: Re: JDK 14 record type representation in classfile format? > [...] > >>> Also, records have an "InnerClasses" class attribute, with an inner class >>> name of "java.lang.invoke.MethodHandles$Lookup" and an outer class name of >>> "java.lang.invoke.MethodHandles". Normally the outer class name matches the >>> class whose classfile the attribute is contained in. Why is this inner >>> class attribute there, and why does the outer class name not match the name >>> of the record? >> This look like a bug to me. > I've created https://bugs.openjdk.java.net/browse/JDK-8241398 to track that. > > cheers, > R?mi From luke.hutch at gmail.com Sat Mar 21 18:13:51 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Sat, 21 Mar 2020 12:13:51 -0600 Subject: JDK 14 record type representation in classfile format? In-Reply-To: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> Message-ID: Sorry for posting to the wrong list. On Sat, Mar 21, 2020 at 12:00 PM Remi Forax wrote: > there is a link just below the JVM spec about record because as you said, > it's a preview feature > > https://docs.oracle.com/javase/specs/jvms/se14/preview/specs/records-jvms.html Thanks for the link. Records still define private fields. Is there any reason to believe that the private fields listed in a record's classfile will not always have an exact 1:1 correspondence to record_component_info entries? i.e. is the information (names, types, arity, etc.) always exactly equivalent between both places? From brian.goetz at oracle.com Sat Mar 21 20:59:48 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 21 Mar 2020 16:59:48 -0400 Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> Message-ID: > Thanks for the link. Records still define private fields. Is there any > reason to believe that the private fields listed in a > record's classfile will not always have an exact 1:1 correspondence > to record_component_info entries? i.e. is the information (names, > types, arity, etc.) always exactly equivalent between both places? Yes.? This is a forced move, as you need to be able to explicitly implement accessor methods, equals, etc, which mean the implementation needs access to the state, and it would be silly to put it anywhere other than fields with the names of the components. record R(int x) { ??? public int x() { ??????? println("X-ing!"); ??????? return x; ??? } } From vicente.romero at oracle.com Sat Mar 21 21:52:43 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 21 Mar 2020 17:52:43 -0400 Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> Message-ID: <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> cc'ing compiler-dev OK the discussion has continued on the JBS entry see [1]. I think now that javac is generating an InnerClasses attribute just because a code that is used to generate signatures is being reused here to generate the descriptor for the bootstrap method. This seems to be the only reason why an InnerClasses attribute is generated whenever there a class refers / uses a bootstrap method. The thing is that as this code has been around since a while, I'm not sure if some other code in the VM or reflection could be depending on it. Does anybody can shed some light on this issue? Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8241398 On 3/21/20 4:19 PM, Vicente Romero wrote: > I don't think that this is a bug. Records are using indy to invoke > bootstrap methods that implement: toString, equals and hashCode. The > first parameter of every bootstrap method is: > java/lang/invoke/MethodHandles$Lookup which is an inner class and thus > requires a dedicated InnerClasses attribute. You can reproduce a very > similar pattern with any code that uses bootstrap methods like: > > class StringTest { > ??? String m(String s) { > ??????? return s + ""; > ??? } > } > > Thanks, > Vicente > > On 3/21/20 4:01 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Remi Forax" >>> ?: "Luke Hutchison" >>> Cc: "jdk-dev" , "amber-dev" >>> >>> Envoy?: Samedi 21 Mars 2020 19:00:04 >>> Objet: Re: JDK 14 record type representation in classfile format? >> [...] >> >>>> Also, records have an "InnerClasses" class attribute, with an inner >>>> class >>>> name of "java.lang.invoke.MethodHandles$Lookup" and an outer class >>>> name of >>>> "java.lang.invoke.MethodHandles". Normally the outer class name >>>> matches the >>>> class whose classfile the attribute is contained in. Why is this inner >>>> class attribute there, and why does the outer class name not match >>>> the name >>>> of the record? >>> This look like a bug to me. >> I've created https://bugs.openjdk.java.net/browse/JDK-8241398 to >> track that. >> >> cheers, >> R?mi > From luke.hutch at gmail.com Sat Mar 21 23:42:26 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Sat, 21 Mar 2020 17:42:26 -0600 Subject: JDK 14 record type representation in classfile format? In-Reply-To: <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> Message-ID: In classes I have looked at in the past, if there is an InnerClasses class attribute, then the listed inner class containment hierarchy always forms a tree rooted at the defining class, and with the tree structure defined by the outer_class_info and inner_class_info entries in the InnerClasses attribute. In this case, the outer_class_info is for MethodHandle, and MethodHandle is not actually an inner class of the record class, so it seems strange that the record class would list MethodHandle$Lookup as an inner class, rather than the MethodHandle class listing MethodHandle$Lookup as an inner class. (I admit I don't understand how bootstrap methods work at the deepest level though, so maybe I'm missing something.) From brian.goetz at oracle.com Sun Mar 22 15:31:17 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 22 Mar 2020 11:31:17 -0400 Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> Message-ID: This does not appear to be specific to records at all; javac seems to generate an IC attribute whenever you _use_ a nested class.? For example: import java.lang.invoke.*; public class Foo { ??? MethodHandles.Lookup lookup = null; } has the following attribute in it: InnerClasses: ? public static final #7= #6 of #20;????? // Lookup=class java/lang/invoke/MethodHandles$Lookup of class java/lang/invoke/MethodHandles While this has nothing to do with records, it may still be worth discussing whether this attribute is necessary, incorrect, or harmful.?? (Note that Lookup is a _nested_ class of MethodHandles, but not an _inner_ one, since it is static.) On 3/21/2020 7:42 PM, Luke Hutchison wrote: > In classes I have looked at in the past, if there is an InnerClasses class > attribute, then the listed inner class containment hierarchy always forms a > tree rooted at the defining class, and with the tree structure defined by > the outer_class_info and inner_class_info entries in the InnerClasses > attribute. > > In this case, the outer_class_info is for MethodHandle, and MethodHandle is > not actually an inner class of the record class, so it seems strange that > the record class would list MethodHandle$Lookup as an inner class, rather > than the MethodHandle class listing MethodHandle$Lookup as an inner class. > > (I admit I don't understand how bootstrap methods work at the deepest level > though, so maybe I'm missing something.) From forax at univ-mlv.fr Sun Mar 22 15:54:23 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 22 Mar 2020 16:54:23 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> Message-ID: <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Luke Hutchison" , "Vicente Romero" > Cc: "amber-dev" , "compiler-dev" > Envoy?: Dimanche 22 Mars 2020 16:31:17 > Objet: Re: JDK 14 record type representation in classfile format? > This does not appear to be specific to records at all; javac seems to > generate an IC attribute whenever you _use_ a nested class.? For example: > > import java.lang.invoke.*; > public class Foo { > ??? MethodHandles.Lookup lookup = null; > } > > has the following attribute in it: > > InnerClasses: > ? public static final #7= #6 of #20;????? // Lookup=class > java/lang/invoke/MethodHandles$Lookup of class > java/lang/invoke/MethodHandles not exactly, here you are declaring lookup as a field. If lookup is a local variable the attribute InnerClasses is not present. public class Foo { public static void main(String[] args) { MethodHandles.Lookup lookup = null; } } > > > While this has nothing to do with records, it may still be worth > discussing whether this attribute is necessary, incorrect, or harmful. > (Note that Lookup is a _nested_ class of MethodHandles, but not an > _inner_ one, since it is static.) > R?mi > > On 3/21/2020 7:42 PM, Luke Hutchison wrote: >> In classes I have looked at in the past, if there is an InnerClasses class >> attribute, then the listed inner class containment hierarchy always forms a >> tree rooted at the defining class, and with the tree structure defined by >> the outer_class_info and inner_class_info entries in the InnerClasses >> attribute. >> >> In this case, the outer_class_info is for MethodHandle, and MethodHandle is >> not actually an inner class of the record class, so it seems strange that >> the record class would list MethodHandle$Lookup as an inner class, rather >> than the MethodHandle class listing MethodHandle$Lookup as an inner class. >> >> (I admit I don't understand how bootstrap methods work at the deepest level > > though, so maybe I'm missing something.) From forax at univ-mlv.fr Sun Mar 22 16:06:00 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 22 Mar 2020 17:06:00 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> Message-ID: <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> To me, it seems to be needed for the separate compilation, when javac reads the type of a class members that contains a '$', it has no idea if it's an inner class or not, the attributes InnerClasses is there to disambiguate. If i'm right, this attributes is not needed in records equals/hashCode/toString or when doing a string concat because in both cases, those operations are inside the bytecode. R?mi ----- Mail original ----- > De: "Remi Forax" > ?: "Brian Goetz" > Cc: "amber-dev" , "compiler-dev" , "Luke Hutchison" > > Envoy?: Dimanche 22 Mars 2020 16:54:23 > Objet: Re: JDK 14 record type representation in classfile format? > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Luke Hutchison" , "Vicente Romero" >> >> Cc: "amber-dev" , "compiler-dev" >> >> Envoy?: Dimanche 22 Mars 2020 16:31:17 >> Objet: Re: JDK 14 record type representation in classfile format? > >> This does not appear to be specific to records at all; javac seems to >> generate an IC attribute whenever you _use_ a nested class.? For example: >> >> import java.lang.invoke.*; >> public class Foo { >> ??? MethodHandles.Lookup lookup = null; >> } >> >> has the following attribute in it: >> >> InnerClasses: >> ? public static final #7= #6 of #20;????? // Lookup=class >> java/lang/invoke/MethodHandles$Lookup of class >> java/lang/invoke/MethodHandles > > > not exactly, here you are declaring lookup as a field. > If lookup is a local variable the attribute InnerClasses is not present. > > public class Foo { > public static void main(String[] args) { > MethodHandles.Lookup lookup = null; > } > } > >> >> >> While this has nothing to do with records, it may still be worth >> discussing whether this attribute is necessary, incorrect, or harmful. >> (Note that Lookup is a _nested_ class of MethodHandles, but not an >> _inner_ one, since it is static.) >> > > > R?mi > >> >> On 3/21/2020 7:42 PM, Luke Hutchison wrote: >>> In classes I have looked at in the past, if there is an InnerClasses class >>> attribute, then the listed inner class containment hierarchy always forms a >>> tree rooted at the defining class, and with the tree structure defined by >>> the outer_class_info and inner_class_info entries in the InnerClasses >>> attribute. >>> >>> In this case, the outer_class_info is for MethodHandle, and MethodHandle is >>> not actually an inner class of the record class, so it seems strange that >>> the record class would list MethodHandle$Lookup as an inner class, rather >>> than the MethodHandle class listing MethodHandle$Lookup as an inner class. >>> >>> (I admit I don't understand how bootstrap methods work at the deepest level > > > though, so maybe I'm missing something.) From maurizio.cimadamore at oracle.com Mon Mar 23 15:52:18 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 15:52:18 +0000 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> Hi Jan, the code looks generally good. I have some high-level questions: * it would be useful to see what kind of diagnostics are generated - I see some weird ones in the golden files (e.g. "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") * this might be a spec issue - there seems to be no support for varargs extraction - e.g. if a record is varargs: record Foo(int... is) { } shouldn't I be able to do this: if (o instanceof Foo(int i1, int i2, int i3)) { ... } Some more detailed comments below: * Attr.java - verifyCastable seems very similar to Check.checkCastable, except for non-reifiable types - should we try to unify a bit? * Attr.java - not sure I get the logic by which target type is propagated or not in visitDeconstructionPattern. Seems to me that the only case where you need propagation is when you have a nested component of the kind "var x" - in which case the type is determined by the expected record component type. But this: + boolean nestedIsValidPattern = !nestedPatterns.head.hasTag(BINDINGPATTERN) || + ((JCBindingPattern) nestedPatterns.head).vartype == null; Seems to point to a slightly different direction? - e.g. target type is propagated even if the nested is a deconstruction pattern, but then I don't see any use of resultInfo inside this visitor? * parser changes - looks good :-) * TransPattern - as usual, some comments illustrating basic desugared shapes would be nice Maurizio On 19/03/2020 17:25, Jan Lahoda wrote: > Hi, > > Turned out the patch had two bugs - one related to the owners of the > temporary variables created, which then broke type annotations; and > another that broken de-duplication. I am deeply sorry for that. An > updated webrev is here: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ > > A delta from previous round: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ > > I am sorry for any inconvenience. > > Jan > > On 18. 03. 20 9:55, Jan Lahoda wrote: >> Hi, >> >> I would like to ask for a review for a patch that implements the >> deconstruction patterns, as described in JEP 375: >> https://bugs.openjdk.java.net/browse/JDK-8235186 >> >> The current specification draft is here: >> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >> >> >> For this phase, the proposal is for javac to desugar the >> deconstruction patterns using record accessors. >> >> The CSR for this change is being written here: >> https://bugs.openjdk.java.net/browse/JDK-8240999 >> >> The proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >> >> Any feedback is welcome! >> >> Thanks, >> ???? Jan From jan.lahoda at oracle.com Tue Mar 24 16:30:09 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 24 Mar 2020 16:30:09 +0000 Subject: hg: amber/amber: Reflecting review comments. Message-ID: <202003241630.02OGU9EI025580@aojmv0008.oracle.com> Changeset: 4e10e0fc162c Author: jlahoda Date: 2020-03-24 17:29 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4e10e0fc162c Reflecting review comments. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java ! test/langtools/tools/javac/patterns/SimpleDeconstructionPattern.java From jan.lahoda at oracle.com Wed Mar 25 08:54:05 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Mar 2020 09:54:05 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> Message-ID: <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> Hi Maurizio, Thanks for the comments! An updated version of the patch is here: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ diff to previous patch: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ On 23. 03. 20 16:52, Maurizio Cimadamore wrote: > Hi Jan, > the code looks generally good. I have some high-level questions: > > * it would be useful to see what kind of diagnostics are generated - I > see some weird ones in the golden files (e.g. > "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") Diag samples: http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html Output of DeconstructionPatternErrors: http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt Regarding the compiler.misc.type.none (which maps to "") - this is in a case where there are too many nested patterns in the deconstruction pattern, and the trailing nested pattern(s) is/are "var" pattern(s). So this is some kind of indeterminable type, and "" does not seem too off. > > * this might be a spec issue - there seems to be no support for varargs > extraction - e.g. if a record is varargs: > > record Foo(int... is) { } > > shouldn't I be able to do this: > > if (o instanceof Foo(int i1, int i2, int i3)) { ... } I believe the spec does not currently allow this, although I assume there will be discussions about features like this in the future. > > > Some more detailed comments below: > > * Attr.java - verifyCastable seems very similar to Check.checkCastable, > except for non-reifiable types - should we try to unify a bit? > > * Attr.java - not sure I get the logic by which target type is > propagated or not in visitDeconstructionPattern. Seems to me that the > only case where you need propagation is when you have a nested component > of the kind "var x" - in which case the type is determined by the > expected record component type. But this: > > + boolean nestedIsValidPattern = > !nestedPatterns.head.hasTag(BINDINGPATTERN) || > + ((JCBindingPattern) nestedPatterns.head).vartype == null; > > Seems to point to a slightly different direction? - e.g. target type is > propagated even if the nested is a deconstruction pattern, but then I > don't see any use of resultInfo inside this visitor? Probably a remainder of any patterns. I've cleaned this up. > > * parser changes - looks good :-) > > * TransPattern - as usual, some comments illustrating basic desugared > shapes would be nice Done. Thanks, Jan > > Maurizio > > On 19/03/2020 17:25, Jan Lahoda wrote: >> Hi, >> >> Turned out the patch had two bugs - one related to the owners of the >> temporary variables created, which then broke type annotations; and >> another that broken de-duplication. I am deeply sorry for that. An >> updated webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >> >> A delta from previous round: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >> >> I am sorry for any inconvenience. >> >> Jan >> >> On 18. 03. 20 9:55, Jan Lahoda wrote: >>> Hi, >>> >>> I would like to ask for a review for a patch that implements the >>> deconstruction patterns, as described in JEP 375: >>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>> >>> The current specification draft is here: >>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>> >>> >>> For this phase, the proposal is for javac to desugar the >>> deconstruction patterns using record accessors. >>> >>> The CSR for this change is being written here: >>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>> >>> The proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ???? Jan From maurizio.cimadamore at oracle.com Wed Mar 25 19:25:06 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 25 Mar 2020 19:25:06 +0000 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> Message-ID: <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> On 25/03/2020 08:54, Jan Lahoda wrote: > Hi Maurizio, > > Thanks for the comments! > > An updated version of the patch is here: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ > diff to previous patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ Looks good - minor nit, in the comments in TransPattern: //PATTn for record component COMPn of type Tn; + //PATTn is a type test pattern or a deconstruction pattern: + //=> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); ) + //or + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn != null && ) + //or + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn instanceof T' && ) Shouldn't we use either or in all of them, consistently? That's what the code appears to be doing. > On 23. 03. 20 16:52, Maurizio Cimadamore wrote: >> Hi Jan, >> the code looks generally good. I have some high-level questions: >> >> * it would be useful to see what kind of diagnostics are generated - >> I see some weird ones in the golden files (e.g. >> "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") > > Diag samples: > http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html > > Output of DeconstructionPatternErrors: > http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt > Thanks! Look good. > > Regarding the compiler.misc.type.none (which maps to "") - this > is in a case where there are too many nested patterns in the > deconstruction pattern, and the trailing nested pattern(s) is/are > "var" pattern(s). So this is some kind of indeterminable type, and > "" does not seem too off. I'd suggest to use the tree printing machinery we have for deferred type arguments in the rich diagnostic formatter - that would give you better results, I believe. Not sure if I'd prefer to break down this: "deconstruction patterns can only be applied to records, String is not a record" into: "invalid deconstruction pattern" "String is not a record" Maurizio > >> >> * this might be a spec issue - there seems to be no support for >> varargs extraction - e.g. if a record is varargs: >> >> record Foo(int... is) { } >> >> shouldn't I be able to do this: >> >> if (o instanceof Foo(int i1, int i2, int i3)) { ... } > > I believe the spec does not currently allow this, although I assume > there will be discussions about features like this in the future. Ok > >> >> >> Some more detailed comments below: >> >> * Attr.java - verifyCastable seems very similar to >> Check.checkCastable, except for non-reifiable types - should we try >> to unify a bit? >> >> * Attr.java - not sure I get the logic by which target type is >> propagated or not in visitDeconstructionPattern. Seems to me that the >> only case where you need propagation is when you have a nested >> component of the kind "var x" - in which case the type is determined >> by the expected record component type. But this: >> >> + boolean nestedIsValidPattern = >> !nestedPatterns.head.hasTag(BINDINGPATTERN) || >> + ((JCBindingPattern) nestedPatterns.head).vartype == null; >> >> Seems to point to a slightly different direction? - e.g. target type >> is propagated even if the nested is a deconstruction pattern, but >> then I don't see any use of resultInfo inside this visitor? > > Probably a remainder of any patterns. I've cleaned this up. > >> >> * parser changes - looks good :-) >> >> * TransPattern - as usual, some comments illustrating basic desugared >> shapes would be nice > > Done. > > Thanks, > ??? Jan > >> >> Maurizio >> >> On 19/03/2020 17:25, Jan Lahoda wrote: >>> Hi, >>> >>> Turned out the patch had two bugs - one related to the owners of the >>> temporary variables created, which then broke type annotations; and >>> another that broken de-duplication. I am deeply sorry for that. An >>> updated webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >>> >>> A delta from previous round: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >>> >>> I am sorry for any inconvenience. >>> >>> Jan >>> >>> On 18. 03. 20 9:55, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I would like to ask for a review for a patch that implements the >>>> deconstruction patterns, as described in JEP 375: >>>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>>> >>>> The current specification draft is here: >>>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>>> >>>> >>>> For this phase, the proposal is for javac to desugar the >>>> deconstruction patterns using record accessors. >>>> >>>> The CSR for this change is being written here: >>>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>>> >>>> The proposed patch: >>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> ???? Jan From jan.lahoda at oracle.com Thu Mar 26 12:10:05 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Thu, 26 Mar 2020 12:10:05 +0000 Subject: hg: amber/amber: Cleanup desugaring comments, as suggested on the review. Message-ID: <202003261210.02QCA6eJ011843@aojmv0008.oracle.com> Changeset: 7f691bf77e1f Author: jlahoda Date: 2020-03-26 13:01 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/7f691bf77e1f Cleanup desugaring comments, as suggested on the review. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java From jan.lahoda at oracle.com Thu Mar 26 15:14:10 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Thu, 26 Mar 2020 15:14:10 +0000 Subject: hg: amber/amber: Fixing out file. Message-ID: <202003261514.02QFEBeO028669@aojmv0008.oracle.com> Changeset: 6aefa65d8f76 Author: jlahoda Date: 2020-03-26 16:13 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6aefa65d8f76 Fixing out file. ! test/langtools/tools/javac/patterns/SimpleDeconstructionPatternNoPreview.out From jan.lahoda at oracle.com Fri Mar 27 10:35:43 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 27 Mar 2020 11:35:43 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> Message-ID: <5eaa7292-4e49-7d04-9fbd-6ec508804f24@oracle.com> On 25. 03. 20 20:25, Maurizio Cimadamore wrote: > > On 25/03/2020 08:54, Jan Lahoda wrote: >> Hi Maurizio, >> >> Thanks for the comments! >> >> An updated version of the patch is here: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ >> diff to previous patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ > > Looks good - minor nit, in the comments in TransPattern: > > //PATTn for record component COMPn of type Tn; > + //PATTn is a type test pattern or a deconstruction pattern: > + //=> > + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); ) > + //or > + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn != null && > ) > + //or > + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn instanceof T' && > ) > > > Shouldn't we use either or in all > of them, consistently? That's what the code appears to be doing. Thanks, I've updated the comments (+one golden output). Full Webrev: https://cr.openjdk.java.net/~jlahoda/8240998/webrev.03/ Delta from previous: https://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.02.03/ Does this look better? Thanks, Jan > > >> On 23. 03. 20 16:52, Maurizio Cimadamore wrote: >>> Hi Jan, >>> the code looks generally good. I have some high-level questions: >>> >>> * it would be useful to see what kind of diagnostics are generated - >>> I see some weird ones in the golden files (e.g. >>> "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") >> >> Diag samples: >> http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html >> >> Output of DeconstructionPatternErrors: >> http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt >> > Thanks! Look good. >> >> Regarding the compiler.misc.type.none (which maps to "") - this >> is in a case where there are too many nested patterns in the >> deconstruction pattern, and the trailing nested pattern(s) is/are >> "var" pattern(s). So this is some kind of indeterminable type, and >> "" does not seem too off. > > I'd suggest to use the tree printing machinery we have for deferred type > arguments in the rich diagnostic formatter - that would give you better > results, I believe. > > Not sure if I'd prefer to break down this: > > "deconstruction patterns can only be applied to records, String is not a > record" > > into: > > "invalid deconstruction pattern" > > "String is not a record" > > Maurizio > >> >>> >>> * this might be a spec issue - there seems to be no support for >>> varargs extraction - e.g. if a record is varargs: >>> >>> record Foo(int... is) { } >>> >>> shouldn't I be able to do this: >>> >>> if (o instanceof Foo(int i1, int i2, int i3)) { ... } >> >> I believe the spec does not currently allow this, although I assume >> there will be discussions about features like this in the future. > Ok >> >>> >>> >>> Some more detailed comments below: >>> >>> * Attr.java - verifyCastable seems very similar to >>> Check.checkCastable, except for non-reifiable types - should we try >>> to unify a bit? >>> >>> * Attr.java - not sure I get the logic by which target type is >>> propagated or not in visitDeconstructionPattern. Seems to me that the >>> only case where you need propagation is when you have a nested >>> component of the kind "var x" - in which case the type is determined >>> by the expected record component type. But this: >>> >>> + boolean nestedIsValidPattern = >>> !nestedPatterns.head.hasTag(BINDINGPATTERN) || >>> + ((JCBindingPattern) nestedPatterns.head).vartype == null; >>> >>> Seems to point to a slightly different direction? - e.g. target type >>> is propagated even if the nested is a deconstruction pattern, but >>> then I don't see any use of resultInfo inside this visitor? >> >> Probably a remainder of any patterns. I've cleaned this up. >> >>> >>> * parser changes - looks good :-) >>> >>> * TransPattern - as usual, some comments illustrating basic desugared >>> shapes would be nice >> >> Done. >> >> Thanks, >> ??? Jan >> >>> >>> Maurizio >>> >>> On 19/03/2020 17:25, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Turned out the patch had two bugs - one related to the owners of the >>>> temporary variables created, which then broke type annotations; and >>>> another that broken de-duplication. I am deeply sorry for that. An >>>> updated webrev is here: >>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >>>> >>>> A delta from previous round: >>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >>>> >>>> I am sorry for any inconvenience. >>>> >>>> Jan >>>> >>>> On 18. 03. 20 9:55, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I would like to ask for a review for a patch that implements the >>>>> deconstruction patterns, as described in JEP 375: >>>>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>>>> >>>>> The current specification draft is here: >>>>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>>>> >>>>> >>>>> For this phase, the proposal is for javac to desugar the >>>>> deconstruction patterns using record accessors. >>>>> >>>>> The CSR for this change is being written here: >>>>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>>>> >>>>> The proposed patch: >>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> ???? Jan From luke.hutch at gmail.com Fri Mar 27 18:19:09 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Fri, 27 Mar 2020 12:19:09 -0600 Subject: JDK 14 record type representation in classfile format? In-Reply-To: <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> Message-ID: On Sun, Mar 22, 2020 at 10:06 AM Remi Forax wrote: > To me, it seems to be needed for the separate compilation, > when javac reads the type of a class members that contains a '$', it has > no idea if it's an inner class or not, > the attributes InnerClasses is there to disambiguate. > But the java.lang.invoke.MethodHandles$Lookup class itself contains an InnerClasses attribute with the mapping of innerClass = "java.lang.invoke.MethodHandles$Lookup", outerClass = "java.lang.invoke.MethodHandles". So the JRE can resolve this by looking at the Lookup itself, which logically should be the intent. I don't see why this information would need to be duplicated in every class that needs access to the Lookup class due to the use of bootstrap methods. That does not seem right to me. From forax at univ-mlv.fr Fri Mar 27 19:09:28 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 27 Mar 2020 20:09:28 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> Message-ID: <1713523742.1496394.1585336168925.JavaMail.zimbra@u-pem.fr> > De: "Luke Hutchison" > ?: "Remi Forax" > Cc: "Brian Goetz" , "amber-dev" > , "compiler-dev" > Envoy?: Vendredi 27 Mars 2020 19:19:09 > Objet: Re: JDK 14 record type representation in classfile format? > On Sun, Mar 22, 2020 at 10:06 AM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> To me, it seems to be needed for the separate compilation, >> when javac reads the type of a class members that contains a '$', it has no idea >> if it's an inner class or not, >> the attributes InnerClasses is there to disambiguate. > But the java.lang.invoke.MethodHandles$Lookup class itself contains an > InnerClasses attribute with the mapping of innerClass = > "java.lang.invoke.MethodHandles$Lookup", outerClass = > "java.lang.invoke.MethodHandles". So the JRE can resolve this by looking at the > Lookup itself, which logically should be the intent. It's not the JRE, it's the compiler. Rewording what you are saying, "the InnerClass attribute is also present at declaration site, so there is no need to have it at use site". > I don't see why this information would need to be duplicated in every class that > needs access to the Lookup class due to the use of bootstrap methods. That does > not seem right to me There is a good reason to duplicate the metadata declared at declaration site at callsite, it means that you can avoid to load the class containing the metadata. Here the compiler can find the classfile of the inner class without finding/loading the outer class. cheers, R?mi From maurizio.cimadamore at oracle.com Sat Mar 28 00:43:41 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 28 Mar 2020 00:43:41 +0000 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <5eaa7292-4e49-7d04-9fbd-6ec508804f24@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> <5eaa7292-4e49-7d04-9fbd-6ec508804f24@oracle.com> Message-ID: <9a45922e-0e00-aef9-416c-be33740a9234@oracle.com> Looks good to me Maurizio On 27/03/2020 10:35, Jan Lahoda wrote: > On 25. 03. 20 20:25, Maurizio Cimadamore wrote: >> >> On 25/03/2020 08:54, Jan Lahoda wrote: >>> Hi Maurizio, >>> >>> Thanks for the comments! >>> >>> An updated version of the patch is here: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ >>> diff to previous patch: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ >> >> Looks good - minor nit, in the comments in TransPattern: >> >> //PATTn for record component COMPn of type Tn; >> + //PATTn is a type test pattern or a deconstruction pattern: >> + //=> >> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); ) >> + //or >> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn != null && >> ) >> + //or >> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn instanceof T' >> && ) >> >> >> Shouldn't we use either or in >> all of them, consistently? That's what the code appears to be doing. > > Thanks, I've updated the comments (+one golden output). > > Full Webrev: > https://cr.openjdk.java.net/~jlahoda/8240998/webrev.03/ > > Delta from previous: > https://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.02.03/ > > Does this look better? > > Thanks, > ??? Jan > >> >> >>> On 23. 03. 20 16:52, Maurizio Cimadamore wrote: >>>> Hi Jan, >>>> the code looks generally good. I have some high-level questions: >>>> >>>> * it would be useful to see what kind of diagnostics are generated >>>> - I see some weird ones in the golden files (e.g. >>>> "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") >>> >>> Diag samples: >>> http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html >>> >>> Output of DeconstructionPatternErrors: >>> http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt >>> >> Thanks! Look good. >>> >>> Regarding the compiler.misc.type.none (which maps to "") - >>> this is in a case where there are too many nested patterns in the >>> deconstruction pattern, and the trailing nested pattern(s) is/are >>> "var" pattern(s). So this is some kind of indeterminable type, and >>> "" does not seem too off. >> >> I'd suggest to use the tree printing machinery we have for deferred >> type arguments in the rich diagnostic formatter - that would give you >> better results, I believe. >> >> Not sure if I'd prefer to break down this: >> >> "deconstruction patterns can only be applied to records, String is >> not a record" >> >> into: >> >> "invalid deconstruction pattern" >> >> "String is not a record" >> >> Maurizio >> >>> >>>> >>>> * this might be a spec issue - there seems to be no support for >>>> varargs extraction - e.g. if a record is varargs: >>>> >>>> record Foo(int... is) { } >>>> >>>> shouldn't I be able to do this: >>>> >>>> if (o instanceof Foo(int i1, int i2, int i3)) { ... } >>> >>> I believe the spec does not currently allow this, although I assume >>> there will be discussions about features like this in the future. >> Ok >>> >>>> >>>> >>>> Some more detailed comments below: >>>> >>>> * Attr.java - verifyCastable seems very similar to >>>> Check.checkCastable, except for non-reifiable types - should we try >>>> to unify a bit? >>>> >>>> * Attr.java - not sure I get the logic by which target type is >>>> propagated or not in visitDeconstructionPattern. Seems to me that >>>> the only case where you need propagation is when you have a nested >>>> component of the kind "var x" - in which case the type is >>>> determined by the expected record component type. But this: >>>> >>>> + boolean nestedIsValidPattern = >>>> !nestedPatterns.head.hasTag(BINDINGPATTERN) || >>>> + ((JCBindingPattern) nestedPatterns.head).vartype == null; >>>> >>>> Seems to point to a slightly different direction? - e.g. target >>>> type is propagated even if the nested is a deconstruction pattern, >>>> but then I don't see any use of resultInfo inside this visitor? >>> >>> Probably a remainder of any patterns. I've cleaned this up. >>> >>>> >>>> * parser changes - looks good :-) >>>> >>>> * TransPattern - as usual, some comments illustrating basic >>>> desugared shapes would be nice >>> >>> Done. >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> Maurizio >>>> >>>> On 19/03/2020 17:25, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Turned out the patch had two bugs - one related to the owners of >>>>> the temporary variables created, which then broke type >>>>> annotations; and another that broken de-duplication. I am deeply >>>>> sorry for that. An updated webrev is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >>>>> >>>>> A delta from previous round: >>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >>>>> >>>>> I am sorry for any inconvenience. >>>>> >>>>> Jan >>>>> >>>>> On 18. 03. 20 9:55, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I would like to ask for a review for a patch that implements the >>>>>> deconstruction patterns, as described in JEP 375: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>>>>> >>>>>> The current specification draft is here: >>>>>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>>>>> >>>>>> >>>>>> For this phase, the proposal is for javac to desugar the >>>>>> deconstruction patterns using record accessors. >>>>>> >>>>>> The CSR for this change is being written here: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>>>>> >>>>>> The proposed patch: >>>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>>>>> >>>>>> Any feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ???? Jan From forax at univ-mlv.fr Sat Mar 28 10:24:12 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 28 Mar 2020 11:24:12 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> <1713523742.1496394.1585336168925.JavaMail.zimbra@u-pem.fr> Message-ID: <298933389.1620147.1585391052737.JavaMail.zimbra@u-pem.fr> > De: "Luke Hutchison" > ?: "Remi Forax" > Cc: "Brian Goetz" , "amber-dev" > , "compiler-dev" > Envoy?: Samedi 28 Mars 2020 01:06:12 > Objet: Re: JDK 14 record type representation in classfile format? >> There is a good reason to duplicate the metadata declared at declaration site at >> callsite, it means that you can avoid to load the class containing the >> metadata. Here the compiler can find the classfile of the inner class without >> finding/loading the outer class. > But as I mentioned, this information is present as an attribute in Lookup (the > inner class), not just in MethodHandle (the outer class). Therefore you can > determine the outer class without loading the outer class. In fact it has to be > that way, because you can't load the outer class before you know what the outer > class is. > Furthermore if you don't need to load the inner class, there's no reason why you > would need to determine the outer class. So if the inner class is actually > being used, you already have the outer class information, because the inner > class has already been loaded. Nope, the trick is to neither load the outer class nor load the inner class. Let say you have a code that call a method m of a class A, with A seen as a classfile and not as a sourcefile by the compiler. class A { void m(MethodHandles.Lookup l) { ... } } ... A a = ... a.m(lookup); The signature of A::m is (Ljava/lang/invoke/MethodHandle$Lookup;)V but for javac, the variable "lookup" is typed as a MethodHandles.Lookup, so you need to have something that say that java/lang/invoke/MethodHandle$Lookup is MethodHandles.Lookup, this is exactly what you get by adding the attribute InnerClass inside the class A. As you see, you don't need to load MethodHandles or Lookup for get that piece of information. R?mi From daniel.latremoliere at gmail.com Sun Mar 29 16:40:39 2020 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Sun, 29 Mar 2020 18:40:39 +0200 Subject: [Records] Transparency and effects on collections In-Reply-To: <355067327.904881.1584439056846.JavaMail.zimbra@u-pem.fr> References: <4febdb1b-73f0-e87d-6a3d-ff02ff808ac8@oracle.com> <355067327.904881.1584439056846.JavaMail.zimbra@u-pem.fr> Message-ID: Le 17/03/2020 ? 10:57, Remi Forax a ?crit?: > Hi Daniel, > Pooling of Java objects in memory usually do more harm than good, > because you artificially change the liveness of the pooled objects > which doesn't work well with modern GC algorithms. > Obviously, if objects are stored in a database, it can still be a win > but usually the pool is more or less coupled with the ORM and use > off-heap memory. Hi R?mi, Sorry for using terminology from database. I would have better used "Compound map keys" [1, cf. Use cases] to avoid confusion. I am talking only of in-memory (heap) data (not off-heap or in an external database). Pooling objects with short live, by using an object with long live, is usually bad. But, when objects are already long living, pooling objects can be a good thing. > EnumSet/EnumMap are specialized because Enum.ordinal() is a perfect > hashcode function, so you can implement fast and compact set and map. > It's not clear to me why there is a need for a specialized version of > set/map for record given has you said a record is a class. Do we miss > something ? Using example from [1]: |RecordMap| would be implementable as: * |HashMap| which is better for get/set operations. * |HashMap| which is better for operations on mappings filtered most frequently by Person: |map.entrySet().stream().filter(filter, Map.Entry.KEY, |||PersonPlace.PERSON|).forEach(...)|) * |HashMap| which is better for operations on mappings filtered most frequently by Place|: ||map.entrySet().stream().filter(||filter, ||||||Map.Entry.KEY, |PersonPlace.PLACE|).forEach(...)| Best implementation will usually be dependant of developer use cases of the data in records, then the constructor of RecordMap need to require preferred order of fields (provided by developer) to choose corresponding implementation. Creating a typesafe representation allow to rewrite queries on RecordSet/RecordMap. When you have multiple nested levels of HashMap like in preceding response, you can filter on keys of upper level HashMap before, to iterate only on the selected inner level HashMap (the only instances of HashMap containing mappings, matching the full query). It an optimisation, using the delay of Stream API (doing nothing visible before a terminal operation). I can understand that this optimisation could seem to be too specialized to be in JDK code, but when I see that a record is a transparent class, I expect transparency of the fields to be anywhere (read or write but also search) . > About filtering fields value on stream, adding a method isEqual that > takes a mapping function and a value should be enough, > ? Predicate filter = Predicate.isEqual(Company::name, "Apple"); > I remember the lambda EG discuss that method (and its primitive > variations), i don't remember why it's was not added. No more uses than what a developer can do manually by adding a static method on the record (not useful for rewriting queries): |static final Predicate person(final ||Predicate|| filter) {| |??? return record -> filter.test(record.person);||| |}| || > About introducing a typesafe representation of fields, we currently > provide a non-typesafe representation, j.l.r.RecordComponent.There is > no typesafe representation because what :: means on a field is still > an open question. I am only interested in typesafe representation of record field, because a record is not simply a normal class but it is a *transparent * class [1]. Its contract with user allow him to see data in field separately, then to search on field separately. If this typesafe representation is added by defining "::" on a field, this is perfect for me (and this can be added in another future iteration, evolving the records). > And if we go that way, a static final field is not the best > representation in term of classfile because it is initialized too > early. A ldc constantdynamic + a static method or something along that > line is a better idea. It is an implementation problem. I will not enter in this aspect of the problem (only API problem). One side question for developer documentation of records. Will Map.Entry be retrofitted as a record? and why if not? (not found in archive of amber-dev). My understanding of records, Bye, Daniel. [1]: https://cr.openjdk.java.net/~briangoetz/amber/datum.html > *De: *"Brian Goetz" > > *?: *"amber-spec-experts" > *Envoy?: *Lundi 16 Mars 2020 21:24:04 > *Objet: *Fwd: [Records] Transparency and effects on collections > > Received on the -comments list. > > > -------- Forwarded Message -------- > Subject: [Records] Transparency and effects on collections > Date: Wed, 11 Mar 2020 07:45:32 -0700 (PDT) > From: Daniel Latr?moli?re > To: amber-spec-comments at openjdk.java.net > > > > I understand that records are transparent and have correct > equals/hashcode, then are useful as keys in collections. When > trying to find classes to evolve to records, I found classes > having more or less the same use-cases in memory than a > multi-column primary key would have in SQL. > ------------------------------------------------------------------------ > Records are a sugar above classes, like enum but for another use > case, is it planned to have more evolved collections (like enum > has with EnumSet/EnumMap)? Given records are explicitly > transparent, API for pooling records would need to use this > explicit transparency to allow partial queries and not only the > Set/Map exact operations. > > If this is the case, it would probably need some specialised > subtype of Set, like a new RecordSet (similar to a simple table > without join, contrary to SQL). Current Java's Stream API would > probably be perfect with some small enhancements, JPA-like (on a > sub-type RecordStream) allowing to refer directly to the field > to be filtered. > > In this case, the compiler would need to generate for each record > one static field per instance field of the record to allow typed > queries, like in the following example. > > |record R(|||String foo, ...)| {|| > ||?? ...|| > ||}|| > | > desugarized more completely in: > > |class R {|| > ||? public static final RecordField FOO;|| > ||? private String foo;|| > ||?? ...|| > ||}|| > | > It would allow some typed code for partial querying, like: > > |RecordSet keyPool;|| > ||Predicate fooFilter;|| > ||keyPool.stream().filter(R.FOO, fooFilter).forEach(...);|| > | > > Thanks for your attention, > Daniel. > ------------------------------------------------------------------------ > NB: in desugarization, I used standard static fields, like JPA, > and not an enum containing all meta-fields (which would probably > be more correct and efficient). This is due to the lack of JEP 301 > (needed for typed constants in enum). If allowed, the desugarized > record will become something like: > > |class R {|| > ||? public static enum META implements RecordField {|| > ||??? FOO(String.class);|| > ||? }|| > ||? private String foo;|| > ||? ...|| > ||}|| > | > In query, it would be used as R.META.FOO for filtering on field > "foo" of the record: > > |keyPool.stream().filter(R.META.FOO, fooFilter).forEach(...)| > ------------------------------------------------------------------------ > PS: I am not interested in interning records but using them in > pools defined by programmer. Pooling would improve memory and > performance to deduplicate records, because equals would more > frequently succeed at identity test without continuing to real > equality test (field by field). Having specialized implementations > of collections, using fields of records following the order given > by user, would probably be useful for performance against simple > Set/Map: structures like a hierarchical Map of Map of ..., field > by field, can be more efficient if partial queries are frequently > used or if the pool is big. > From luke.hutch at gmail.com Sat Mar 28 00:06:12 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Fri, 27 Mar 2020 18:06:12 -0600 Subject: JDK 14 record type representation in classfile format? In-Reply-To: <1713523742.1496394.1585336168925.JavaMail.zimbra@u-pem.fr> References: <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> <1713523742.1496394.1585336168925.JavaMail.zimbra@u-pem.fr> Message-ID: > > There is a good reason to duplicate the metadata declared at declaration > site at callsite, it means that you can avoid to load the class containing > the metadata. Here the compiler can find the classfile of the inner class > without finding/loading the outer class. > But as I mentioned, this information is present as an attribute in Lookup (the inner class), not just in MethodHandle (the outer class). Therefore you can determine the outer class without loading the outer class. In fact it has to be that way, because you can't load the outer class before you know what the outer class is. Furthermore if you don't need to load the inner class, there's no reason why you would need to determine the outer class. So if the inner class is actually being used, you already have the outer class information, because the inner class has already been loaded.