From valhalla at jinq.org Wed Oct 1 18:10:49 2014 From: valhalla at jinq.org (Ming-Yee Iu) Date: Wed, 1 Oct 2014 14:10:49 -0400 Subject: Mixing up value types and reference types Message-ID: When you get around to working on the syntax for value types, it would be nice if you could find a way to make value types be distinguished from reference types somehow. In C#, I always found it a little confusing that value types looked exactly like reference types in the code, so I could never be exactly sure about what would happen if I wrote A a = b; or return a; without looking at the documentation to see whether A was a value type or not. For example, I might read up on some blog about a function which returns the bounding box of a UI widget as a Rectangle object. I would then want to make a slightly bigger rectangle for the border. Without knowing whether Rectangle was a value type or not, I might write either: Rectangle a = widget.getBounds(); Rectangle border = a; border.x--; border.y--; border.width += 2; border.height += 2; or Rectangle a = widget.getBounds(); Rectangle border = new Rectangle(a.x-1, a.y-1, a.width +=2; a.height+=2); But I would have to look up the documentation first to find out if Rectangle is a value type or not first. I'm not sure if new syntax would actually be the best way of solving the problem. Maybe simply setting some good conventions early on for people to follow would be enough. Obviously, Hungarian notation might be going a bit far, but maybe something as simple as declaring that value types should start with a lower case letter so that they look like primitive types would be sufficient? e.g. int, double, point, rectangle2d, vs. Integer, Double, Point, Rectangle2d -Ming From john.r.rose at oracle.com Wed Oct 1 18:25:12 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Oct 2014 11:25:12 -0700 Subject: Notes about Valhalla from a non-Java perspective In-Reply-To: <542AC7DE.7040905@ochsenreither.de> References: <542AC7DE.7040905@ochsenreither.de> Message-ID: <81B80231-992E-4338-BD60-B3D80FEF82EF@oracle.com> On Sep 30, 2014, at 8:10 AM, Simon Ochsenreither wrote: > Hi, > > it seems that no one from the Scala team found enough time/interest to participate on valhalla-dev (Martin mentioned that most of the Scala team is on holidays/in a move/in recovery) yet ... I would have preferred to not get involved (bad impressions from other OpenJDK lists), but I'll just post my personal notes (which I sent to scala-internals a few weeks earlier) here directly before they fall completely out of date. > > Please note that it's written from a Scala development perspective, so "we" == "arbitrary group of Scala devs/users". Thanks for taking the time to send your notes. Here's a partial reply... The Scala perspective on values is valuable to us, not only because is known to work on the JVM, but because you folks have lived with the implications of your design choices. > Here are my (slightly improved) notes: > > ============== > > * On the general approach of using class file attributes with tuples > of (bytecode index -> type) > It's kind of funny, because that's exactly the approach I took > almost 18 months earlier when I was thinking about this topic. I > considered that to be quite a hack at that time and thought "if the > JVM ever gets this, they will surely come up with a more principled > way of doing this". We have similar opinions on it, and are mulling principled approaches. The type annotations (similar approach) was done under the constraint that the bytecode set was off limits. That is not the case here, so we can add annotation-carrying bytecodes (decorated nops) if we choose. > * vcmp > This feels a bit ad-hoc currently. I think it would be considerably > more useful if they tried to come up with a design which would work > across all types, and not yet-another special case. > > Scala's == implementation for instance is around 100 lines of code > with dozens of branches to work around Java's/the JVM's idea of > equality. It would be nice that if they were adding another > comparison operator that they wouldn't repeat the mistakes of equals > & friends. > > They could be on the right way, but hard to tell without looking at > it more closely. > > My suggestion would be to have a notion of "primitive" equality > which is defined as "do the most basic comparison available": > Compare the bits of the underlying value, which means ... > o the bits of value types, taking types into account > o the bits of the reference for reference types > o wrappers are unboxed > o Double.NaN is equal to itself, 0.0 and -0.0 are not equal "Most basic comparison available" ... "except for certain undesirable, even more basic comparisons." Part of the reason to view values as typed bits is to provide a place for a non-ad-hoc definition of of "most basic" comparison, which is bitwise. That's the current thinking behind vcmp. Anything higher level can be a method, can't it? > > This would be pretty much be in line with our earlier debate about > supporting eq on value types. If this could be encoded as a single > vcmp operation, it would be a huge win. > > Additionally, one could also consider a corresponding operation for > "semantic" equality: > > o Use "equals" implementation for value types > o Use Java-style "==" for primitives > o Wrappers are unboxed > o Use "equals" implementation for references > o Double.NaN is not equal to itself, 0.0 and -0.0 are equal > o (Optionally) Compare arrays by comparing the element > > That would vastly simplify our == implementation, but that's not really the point ... it would be possible to do that, but I think priority should be to prevent vcmp from being either artificially limited to value types or ending up incoherent like the rest of equality stuff in Java. vcmp is a morphed version of [ail]cmp. That's why it is proposed as bitwise. There is no fcmp, so we pull from Double.equals, since that is almost as fundamental. This is obviously an over-constrained design problem, but I will observe that there is a discernible "most basic" comparison, the initial element in the category of comparable representations of a value type. It may strike some as "wait, that's way too basic for me!", but it's fairly unique. > In the end, I think how to deal with primitive wrappers is still an uncharted territory. Retrofitting those wrapper classes as value boxes very likely won't work, so maybe there is more specification required on how "T=Integer" for "any T" is treated (or int in need of a box in specialized code). We doubt existing wrappers can be upgraded to be real value boxes. Watch for "Heisenboxes" for primitives and values. > * No reification for reference types (Reified in the sense of "the > type is available at runtime", not "it gets a specialized class".) > I'm split on this. On the one side, this could give us the escape > hatch for types not expressible with the new Generics, but on the > other hand it would really suck because it would mean we couldn't > just drop ClassTags altogether, but would need to drag them around > for every type even if only references would actually need them. > Additionally, the split between value types/reference types is very > likely not similar to the split we would need to erase Scala's types > to the JVM's level of expressiveness. > It feels like they are again trying to cut corners here, trading > implementation ease for additional language complexity. > (As far as I remember, there were some concerns about what happens > with Java's .class/getClass() when reference types are reified ... > but imho, Java problems should stay Java problems and shouldn't make > the JVM approach worse than necessary.) Also note, how this fits > with my work on making classOf[T] ClassTag-aware. (Insert long conversation about the pros and cons, hows and whys, of reification of Java source-level types to JVM level. There was a lot of this at JavaOne yesterday; sorry I can't recap here.) > > Additionally, we have already an escape hatch with the existing > erased Generics, so having yet-another different style of Generics > doesn't feel like the right way ... which brings us to the next point: > > * Reified/Erased Generics interop > This seems to be a really dark corner. The draft is pretty silent on > this. It currently looks like you can't have a type hierarchy were A > is erased at the top but reified in a a subclass (or the other way > around) ... I think this will make it very hard to use erased > Generics as an escape hatch. Combined with the earlier point, I'd > prefer better reified/erased interop and having reified reference > types with reified Generics. > Otherwise, it feels like tons of people will try to wrap random > reference types in value types to get around that limitation. We will probably provide some sort of opt-in way to track more elaborate representations of compile-time types. But the JVM will always (IMO) tilt towards simplifying runtime types, as a way of making code sharing easier. This doesn't stop programmers from weaving Class and Type token pointers into their data structures, but doesn't require the JVM to do so always. > * No variance for value types > This is a big conceptual problem with heterogeneous translation and > my personal conclusion 1.5 years ago was the same: It can't really > be done without a huge explosion in runtime complexity. This will be something to watch. If you don't explode the runtime complexity, you may have to explode the static complexity (JAR file), right? On the other hand, if you push instantiation to runtime (or link time) you delay code splitting as long as possible, and allow for internal unsafe code sharing (untyped inline mini-boxes, for example). > * Poor man's typeclasses > There was a short mention of "conditional methods", e.g. enabling > methods only for a subset of some generic type. That smells a lot > like a crippled version of typeclasses. Might be useful to watch > what happens in that space. Yes, please do. General question: What is the simplest JVM support needed to make higher-kinded parameterizations efficient? > * Members on any T > There seems to be a debate about whether/how "any T" should expose > methods by itself. While this seems to be nicely in line with what a > lot of people in Scala would like to do, I think Java will not be > able to properly add constraints to T to describe required methods. That's what interfaces are for, on both references and value types. I would expect to see them show up on primitives too, sooner than new categorization mechanisms (which as you say would be wrong from the start, for most languages). > They currently only have upper bounds to express those things, but > even in Scala where bounds are less horrible than in Java, people > have pretty much abandoned bounds based on subtyping in favor of > context bounds. > So even if Any/T wouldn't get any members I think we should be aware > that Java's options for adding constraints are very, very primitive > and probably not what we would want to use in Scala. Let's take that > into account before arguing for or against this ... Maybe there's a way to make interfaces slightly stronger, so they can represent more complex (structural or contextual) constraints. General question: What is the simplest JVM support needed to allow interfaces to support the "next level" of constraints? (Requires some discussion of what is the next level; my preference is emphatically given to widely deployed languages.) > > My conclusion regarding Scala: > > * Exposing two kinds of Generics to the user is highly undesirable > from a language design POV. F# did the same with a much better > starting point than Java (well-designed runtime support for reified > Generics) and even for them I think the increase of complexity just > wasn't worth the benefit. Java might not have a choice here, but I > think we should make sure to not leak these "implementation details" > to the user. We will have to support both kinds of Generics for > interop anyway. Noted. > * We should think about how we would like to see T/Any and eq/== > evolve in the long-term and communicate that clearly to the Valhalla > people. It's probably much more painful if they e.g. decide to have > no members on any T, but decide on an incompatible constraint > mechanism (which would very likely be reified in the bytecode). That > way, keeping status quo and implementing member-free Any/T as a > scalac fiction might work better. We'll do ad hoc constraint mechanisms if we need to, and we are using them while prototyping, but we have both the time and inclination to converge on a reasonably clean final design, if and when one appears. > * We should start preparing for the variance/value type breakage. > People who need variance can migrate to boxed representations easily > (replace Vector[Int] with Vector[Integer] for instance), but trying > to keep things as-is would mean just not supporting JVM value types, > and I think that would be a terrible decision. From a type system > POV, instantiating a type parameter with a value type could be seen > as collapsing all the bounds of that type parameter to make it invariant Thank you for helping us watch this point. We are mulling over options for introducing runtime or instantiation-time variance on value types. Same point here about us having time and inclination, and hoping for better clarity. > * We should really think about having a scalac prototype which tries > to emit the new class file format and leverage the new semantics. > There is already an ASM fork out there with preliminary support, but > I don't know how stable/complete that code is. > Experience has shown (JRuby) that this is the most effective way to > actually influence the design. Yes, the 292 bytecode changes were deeply influenced by JRuby's helpful early adoption. Thanks, ? John > That's just some short overview, I can expand on these topics as necessary, but I expect that people have read the draft proposal and the complete mailing list already so that everyone is on roughly the same level. > > ============== > > I hope this is helpful. > > Thanks, > > Simon From simon at ochsenreither.de Wed Oct 1 22:17:33 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Thu, 2 Oct 2014 00:17:33 +0200 (CEST) Subject: Notes about Valhalla from a non-Java perspective In-Reply-To: <81B80231-992E-4338-BD60-B3D80FEF82EF@oracle.com> References: <542AC7DE.7040905@ochsenreither.de> <81B80231-992E-4338-BD60-B3D80FEF82EF@oracle.com> Message-ID: <1522233891.21140.1412201853998.JavaMail.open-xchange@srv005.service.ps-server.net> Hi John, thanks a lot for your insightful response! > The Scala perspective on values is valuable to us, > not only because is known to work on the JVM, > but because you folks have lived with the implications > of your design choices. I'll try to provide you with as much information as possible. :-) Especially for value types, I think it's extremely important to come up with a good design, because there is a huge difference between Java and Scala. While in Java, value types won't be too widespread due to compatibility issues, I can imagine that most Scala libraries will eventually end up with a majority of value types. Imho, it's very important to make sure that the value class design allows languages/developers to choose what works best for them and not let them hit limitations like "well, this could be a value type, but the JVM doesn't support it because we didn't need it for Java" A good design would support a wide range of reasonable reference-type/value-type ratios regardless of whether it will be more like 80%/20% (Java) or 30%/70% (Scala). But until now, things look good. I haven't seen any huge deal breakers yet, and most of the extra stuff the JVM draft allows is what we wanted to have in Scala, too (e. g. value types with more than one field) but couldn't be implemented due to JVM restrictions. > We have similar opinions on it, and are mulling principled approaches. > The type annotations (similar approach) was done under the constraint > that the bytecode set was off limits. That is not the case here, so we > can add annotation-carrying bytecodes (decorated nops) if we choose. Yes, I found that approach slightly nicer but in the end the question (imho) is ... if there are these huge changes to the bytecode, maybe it would just make sense to flip the switch, go to the drawing board and redesign the class file format, fixing a lot of other issues, too. (Like the 65K method limit.) As an example, the only reason why Scala hasn't adopted https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm yet and still uses name mangling (I wrote the patch to remove name mangling, and it was a huge readability improvement, especially in stacktraces) is because the way inner classes are handled is such a disaster and paulp wanted to keep all those "extra" symbols reserved as a potential $-replacement if he found it to improve things. But I can kind of understand why people don't want to start yet-another huge project. :-) > "Most basic comparison available" ... "except for certain undesirable, > even more basic comparisons." If you refer to the Double stuff, I added that as a more detailed description of what I expect to happen (it is in line with "simply compare type-and-bits"). If you refer to the handling of wrappers, yes ... not sure what's the right approach here. From my point of view, having to potentially deal with java.lang.Double, double and value-boxed double is not desirable. In that sense maybe "any T" can be specified as "wrapped primitives don't exist in here". > Part of the reason to view values as typed bits is to provide a place > for a non-ad-hoc definition of of "most basic" comparison, which is > bitwise. That's the current thinking behind vcmp. Anything higher > level can be a method, can't it? Yes, that's the intention. I think we are pretty much in agreement on what the "primitive comparison" is supposed to do. I'm just unsure how wrappers can fit into it. In the end, we have conceptually two different ways of comparing things, but floating point numbers offer three. (primitive ==, reference == and reference equals), and it would be painful to not being able to abstract over collection element types (e. g. having to write both HashMap[T] and DoubleHashMap, although something similar was proposed earlier ...). > vcmp is a morphed version of [ail]cmp. That's why it is proposed as bitwise. > There is no fcmp, so we pull from Double.equals, since that is almost as > fundamental. > This is obviously an over-constrained design problem, but I will observe > that there is a discernible "most basic" comparison, the initial element > in the category of comparable representations of a value type. > It may strike some as "wait, that's way too basic for me!", but it's fairly > unique. I think the general question is what do we expect to happen when people call "equals" on floating-point types. On the one side, I think it would be good not to pull in all the reference-Double craziness, but on the other side, it could lead to things like changes how equals-based collections work (e. g. not being able to remove Double.NaNs from a collection anymore). That was basically the idea behind the "primitive vs. semantic equality" divide: One really really really just compares type-and-bits and the other does more advanced things (like following the IEEE754 behaviour on floating point equality). In the end, one could think of it this way: reference types, value types and primitive types have "primitive" and "semantic" equality: * for most primitive types primitive and semantic are the same (except floating points) * primitive equality is fixed and cannot be changed * semantic equality can be implemented/overridden by the code author for reference and value types. > (Insert long conversation about the pros and cons, hows and whys, > of reification of Java source-level types to JVM level. There was > a lot of this at JavaOne yesterday; sorry I can't recap here.) Yes, I just hope people can come up with a better approach. The current one feels a lot like translating a Java paradigm to the JVM, and I really think that after almost 20 years it would be nice if that sentence about being a language-agnostic runtime would be taken a bit more seriously. > We will probably provide some sort of opt-in way to track more elaborate > representations of compile-time types. But the JVM will always (IMO) > tilt towards simplifying runtime types, as a way of making code sharing > easier. > This doesn't stop programmers from weaving Class and Type token pointers > into their data structures, but doesn't require the JVM to do so always. Sure. This is what scalac has been doing for a lot of years already. The problem is that this passing-types-along has impact on method/class signatures currently, so it is exposed to the user and can create compatibility issues. It would be nice to change/migrate code without breaking every user of that code. > This will be something to watch. If you don't explode the runtime complexity, > you may have to explode the static complexity (JAR file), right? Not sure. From my point of view, and given the time/resource constraints I don't think it is possible to come up with a good solution. Consider this code, assuming specialization: val vector = Vector(1,2,3) // Vector[T] specialized to Int, which means it is backed by an Array[Int] instead of an Array[Object] vector :+ "abc" // What's expected to happen here? I don't think it is realistic that the JIT figures out how to move and box all the values from Array[Int] to an Array[Object], replace the (final!) reference to the Array in Vector, and add "abc" to the Array[Object], etc. Imho, the only practical thing (IF it can be shown to be sound from a language type system POV) is to collapse all bounds/make everything invariant related to a type parameter T when T is instantiated with a value type. > On the other hand, if you push instantiation to runtime (or link time) > you delay code splitting as long as possible, and allow for internal > unsafe code sharing (untyped inline mini-boxes, for example). Mhh, I think this is orthogonal. > Yes, please do. General question: What is the simplest JVM support > needed to make higher-kinded parameterizations efficient? In the sense of higher-kinded types or "higher-kinded" the general sense? > That's what interfaces are for, on both references and value types. > I would expect to see them show up on primitives too, sooner than > new categorization mechanisms (which as you say would be wrong > from the start, for most languages). I think if Java would finally get a useful replacement for the useless java.lang.Number type, that would be great. For some use-cases, like +/*/-/... on numbers, translating a scala.math.Numeric[T]-like typeclass to a Java interface which those types implement makes sense. The caveat is that this won't be usable for things like equality, comparison, hashing, toString, etc., while it would be extremely desirable to have a solution which covers these things, too. (See all those duplicated collections in the standard and third-party libraries in Java, Scala, etc. which basically just exchange the equality function. (HashMap vs. IdentityHashMap in Java, HashMap vs. AnyRefMap in Scala, etc.)) (As far as I remember, the only reason why Scala hardcoded this stuff is because the performance differences between hardcoding and accepting an equality function as input was catastrophic on the JVM.) > Maybe there's a way to make interfaces slightly stronger, so they can > represent more complex (structural or contextual) constraints. > General question: What is the simplest JVM support needed to > allow interfaces to support the "next level" of constraints? > (Requires some discussion of what is the next level; my preference > is emphatically given to widely deployed languages.) I think allowing some kind of dictionary-passing that doesn't impact the visible signatures (in terms of methods parameters) of methods/classes would be an interesting thing to research. Maybe all that is required is some better detection of that pattern by the JIT compiler, because the performance drawbacks are pretty much the only issue in Scala today (The amount of work and careful design happening in e. g. Erik Osheim's et al.s Spire math library to line up things right for the JVM are pretty impressive.) (Actually, Scala's way of passing-a-type-around which I described above is just one usage of context bounds, which are basically dictionary-passing.) Which values are passed around could be completely language-specific then. (E. g., Which values are in scope? Are multiple available values allowed? When are they ambiguous? ... Different languages Scala, Haskell, Idris, Agda, ... will have different opinions on that.) After having used both upper bounds and context bounds, upper bounds are almost never what one actually wants, especially in the cases mentioned above, because equality/comparison/hashing/etc. is not a property of a type, but a relationship between a type and an equality/compare/hash function. This is an interesting thing here ... retrofitting generic interfaces to numbers would certainly be very helpful when working with numbers, but that alone won't work for a lot of different use-cases. > We'll do ad hoc constraint mechanisms if we need to, and we are > using them while prototyping, but we have both the time and inclination > to converge on a reasonably clean final design, if and when one appears. Yes, I think the question really is whether it's possible to come up with a good design which accommodates different languages. > Thank you for helping us watch this point. We are mulling over options > for introducing runtime or instantiation-time variance on value types. > Same point here about us having time and inclination, and hoping for > better clarity. Thanks for the info. I'm really wondering whether there even exists a workable option. I really hope a few additional Scala people show up who know more about which things are conceptually possible (I'm more the expert on which things don't work :-)). Thanks again for your extremely helpful answer! Bye, Simon From simon at ochsenreither.de Wed Oct 1 22:57:32 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Thu, 2 Oct 2014 00:57:32 +0200 (CEST) Subject: Mixing up value types and reference types In-Reply-To: References: Message-ID: <453800982.21151.1412204252596.JavaMail.open-xchange@srv005.service.ps-server.net> Isn't the potential of confusion you have demonstrated more or less a consequence of C#'s decision to allow mutable value types? I'm not strongly claiming that immutable value types don't have this issue (although I would tend to assume it, because I can't remember hitting such an issue in Scala since the introduction of value types). From vitalyd at gmail.com Wed Oct 1 23:17:14 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 1 Oct 2014 19:17:14 -0400 Subject: Mixing up value types and reference types In-Reply-To: <453800982.21151.1412204252596.JavaMail.open-xchange@srv005.service.ps-server.net> References: <453800982.21151.1412204252596.JavaMail.open-xchange@srv005.service.ps-server.net> Message-ID: Even with immutable value types, there's a performance difference between returning a new value type vs reference type or passing it around as a parameter. But can't this be handled by things like the IDE, with different coloring or whatnot? As for mutable value types, they're useful in perf sensitive contexts where they're used simply as identity-less containers of data. Think an array of them. Updating each one via copying into a new one is less than ideal. But that's an aside, carry on :). Sent from my phone On Oct 1, 2014 6:58 PM, "Simon Ochsenreither" wrote: > Isn't the potential of confusion you have demonstrated more or less a > consequence of C#'s decision to allow mutable value types? > > I'm not strongly claiming that immutable value types don't have this issue > (although I would tend to assume it, because I can't remember hitting such > an > issue in Scala since the introduction of value types). > From brian.goetz at oracle.com Mon Oct 13 16:33:12 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 13 Oct 2014 16:33:12 +0000 Subject: hg: valhalla/valhalla/jdk: Fix bug in specializer when last lvar instruction has no entry in BytecodeMapping attribute Message-ID: <201410131633.s9DGXDps000082@aojmv0008> Changeset: f08a28bd842d Author: briangoetz Date: 2014-10-13 12:32 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f08a28bd842d Fix bug in specializer when last lvar instruction has no entry in BytecodeMapping attribute ! src/java.base/share/classes/valhalla/specializer/Specializer.java + test/valhalla/test/valhalla/specializer/SpecializationMetadataTest.java From brian.goetz at oracle.com Mon Oct 13 18:19:47 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Oct 2014 14:19:47 -0400 Subject: Static fields in specialized classes Message-ID: <543C17C3.50104@oracle.com> We stumbled across a few issues regarding static fields in specialized classes in the prototype. There seems to be a reasonably straightforward solution but it does touch quite a number of things. Consider: class Foo { public final static int x = System.currentTimeMillis(); } Regardless of whether our implementation is by specialization or erasure (or both), logically there is just *one* field 'x' for any instantiation Foo. If we take a naive approach to specialization, where we just copy members from Foo to Foo during specialization, we end up with two 'x' fields (wrong). So the specializer should strip out static members during specialization. (If the base class has static members, we also need to add back a clinit member in Foo to force loading of base Foo, to ensure that all instantiations of Foo have a consistent view of Foo's statics.) So then we're done. Except for access through instances (yechh). Here, the compiler needs to rewrite any references to f.x (where f is an instance of a specialization of Foo) to Foo.x, and we're done. Except for access control; if x is private, then we get an IllegalAccessError on any references to x from within Foo to Foo.x. Which means that Foo has to be loaded as if with a host class of Foo. (Just as defineAnonymousClass supports a host class, classdynamic will need to as well.) So then we're done. Except for reflection; reflection on Foo.class should still show that it has the same static members as Foo, and in fact they *are* the same static members. So then we're done. Except for MH lookup. Will need to fix that up too. Any others? From david.r.chase at oracle.com Mon Oct 13 18:26:26 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 13 Oct 2014 14:26:26 -0400 Subject: Static fields in specialized classes In-Reply-To: <543C17C3.50104@oracle.com> References: <543C17C3.50104@oracle.com> Message-ID: On 2014-10-13, at 2:19 PM, Brian Goetz wrote: > Consider: > > class Foo { > public final static int x = System.currentTimeMillis(); > } > > Regardless of whether our implementation is by specialization or erasure (or both), logically there is just *one* field 'x' for any instantiation Foo. How sure are you that this is true? What if the type of static final x happens to be ?T?? (nonsensical when erased, but not when reified) David From brian.goetz at oracle.com Mon Oct 13 18:46:26 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Oct 2014 14:46:26 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> Message-ID: <543C1E02.9010501@oracle.com> >> Regardless of whether our implementation is by specialization or >> erasure (or both), logically there is just *one* field 'x' for any >> instantiation Foo. > > How sure are you that this is true? What if the type of static final > x happens to be ?T?? (nonsensical when erased, but not when reified) Currently the rules still prohibit T to appear in member signatures, so that's currently a non-issue, but there are potential surprising behaviors in either direction, and the question is which interpretation is less surprising. Consider this: class Foo { static int fooCount; public void foo() { ++fooCount; } } Based on how generics have worked since 2004, users will expect that there is one fooCount field that is incremented each time foo() is called on any instance of a Foo. Having only some Foo instances participate in this game, but not others, would be surprising. Stepping back, statics are the root of much evil in Java in the first place. So, while one could build a more generalized notion of statics in the context of reified generics as you suggest, I'm inclined to politely decline that option. From vitalyd at gmail.com Mon Oct 13 19:09:18 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 Oct 2014 15:09:18 -0400 Subject: Static fields in specialized classes In-Reply-To: <543C1E02.9010501@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> Message-ID: As a user, I would *not* expect that there's just one fooCount field for all Foo instances. Maybe this is because I also know .NET, where a static field in a generic type is "replicated" into all closed types over T (granted, generics are reified there, but if java were to reify or specialize, then I don't see anything wrong with replicating the statics into the specializations). And yes, putting statics into generic classes is frowned upon. In fact, tools like Resharper will warn about such occurrences. On Mon, Oct 13, 2014 at 2:46 PM, Brian Goetz wrote: > Regardless of whether our implementation is by specialization or >>> erasure (or both), logically there is just *one* field 'x' for any >>> instantiation Foo. >>> >> >> How sure are you that this is true? What if the type of static final >> x happens to be ?T?? (nonsensical when erased, but not when reified) >> > > Currently the rules still prohibit T to appear in member signatures, so > that's currently a non-issue, but there are potential surprising behaviors > in either direction, and the question is which interpretation is less > surprising. > > Consider this: > > class Foo { > static int fooCount; > > public void foo() { > ++fooCount; > } > } > > Based on how generics have worked since 2004, users will expect that there > is one fooCount field that is incremented each time foo() is called on any > instance of a Foo. Having only some Foo instances participate in > this game, but not others, would be surprising. > > Stepping back, statics are the root of much evil in Java in the first > place. So, while one could build a more generalized notion of statics in > the context of reified generics as you suggest, I'm inclined to politely > decline that option. > > > From brian.goetz at oracle.com Mon Oct 13 19:13:26 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Oct 2014 15:13:26 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> Message-ID: <543C2456.6090708@oracle.com> > As a user, I would *not* expect that there's just one fooCount field for > all Foo instances. Except that's how generics have worked in Java since 2004. Do you propose that existing generic code with statics should change how it behaves? Or are you suggesting that the existing behavior is also counterintuitive? From david.r.chase at oracle.com Mon Oct 13 19:16:21 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 13 Oct 2014 15:16:21 -0400 Subject: Static fields in specialized classes In-Reply-To: <543C2456.6090708@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> Message-ID: I think we?ve become accustomed to some of the artifacts that result from erasure-based generics. That?s not the same as intuitive. David On 2014-10-13, at 3:13 PM, Brian Goetz wrote: >> As a user, I would *not* expect that there's just one fooCount field for >> all Foo instances. > > Except that's how generics have worked in Java since 2004. Do you propose that existing generic code with statics should change how it behaves? Or are you suggesting that the existing behavior is also counterintuitive? From vitalyd at gmail.com Mon Oct 13 19:20:26 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 Oct 2014 15:20:26 -0400 Subject: Static fields in specialized classes In-Reply-To: <543C2456.6090708@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> Message-ID: Sure, I don't dismiss the historical aspect of this. However, I don't necessarily think this should be a barrier if generics were to be reified or specialization introduced. In that case, people should become aware of what's happening with their static fields, and once they do, I don't think they'll find it unintuitive given the new context. I think it's intuitive to think of generic types (in a specialized/reified world) as recipes/templates/"super macros" for concrete instantiations, and given that, it makes sense (to me, at least) that the static fields are replicated across the actual instantiations. On Mon, Oct 13, 2014 at 3:13 PM, Brian Goetz wrote: > As a user, I would *not* expect that there's just one fooCount field for >> all Foo instances. >> > > Except that's how generics have worked in Java since 2004. Do you propose > that existing generic code with statics should change how it behaves? Or > are you suggesting that the existing behavior is also counterintuitive? > From maurizio.cimadamore at oracle.com Mon Oct 13 22:38:51 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Oct 2014 23:38:51 +0100 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> Message-ID: <543C547B.5000809@oracle.com> Interesting discussion, although I wonder how much we are being biased by how the current implementation works; let's imagine a world where type specialization is not needed - we can have a single erased/templating format that suits all parameterizations (of course you'd need an expressive enough instruction set) - if that's the case, you'll have a single *class *generating multiple *types* with no need for specialization. Would that change the perception of statics when it come to generic classes? The key thing about generics is that they change the relation between classes and types in a fundamental way - before JDK 5 for each class you'd get one type (1:1). After JDK 5, one class can be instantiated to multiple parameterized types (1:N). In the Java language, the word 'static' is typically used to denote 'class'-wide properties. Think about locks - locking on a static field F means locking on the class instance representing the class defining F. I think the meaning of programs should be preserved as much as possible before/after reification; it might seem that, as primitive/values in generics were never allowed before, we have more freedom here - but we must think about reference types in the back of our head: do we really want to change the meaning of programs accessing static fields on Foo vs. Foo ? Maurizio On 13/10/14 20:20, Vitaly Davidovich wrote: > Sure, I don't dismiss the historical aspect of this. However, I don't > necessarily think this should be a barrier if generics were to be reified > or specialization introduced. In that case, people should become aware of > what's happening with their static fields, and once they do, I don't think > they'll find it unintuitive given the new context. I think it's intuitive > to think of generic types (in a specialized/reified world) as > recipes/templates/"super macros" for concrete instantiations, and given > that, it makes sense (to me, at least) that the static fields are > replicated across the actual instantiations. > > On Mon, Oct 13, 2014 at 3:13 PM, Brian Goetz wrote: > >> As a user, I would *not* expect that there's just one fooCount field for >>> all Foo instances. >>> >> Except that's how generics have worked in Java since 2004. Do you propose >> that existing generic code with statics should change how it behaves? Or >> are you suggesting that the existing behavior is also counterintuitive? >> From maurizio.cimadamore at oracle.com Mon Oct 13 22:42:32 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Oct 2014 23:42:32 +0100 Subject: Static fields in specialized classes In-Reply-To: <543C547B.5000809@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> <543C547B.5000809@oracle.com> Message-ID: <543C5558.9070209@oracle.com> On 13/10/14 23:38, Maurizio Cimadamore wrote: > Think about locks - locking on a static field F means locking on the > class instance representing the class defining F Sorry - the example I had in mind was calling a synchronized static method - the essence of the message is the same... Maurizio From vitalyd at gmail.com Mon Oct 13 23:04:23 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 Oct 2014 19:04:23 -0400 Subject: Static fields in specialized classes In-Reply-To: <543C547B.5000809@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> <543C547B.5000809@oracle.com> Message-ID: The issue is that since java doesn't reify generics, users know that there's just one type. My argument is that if there's reification, then generic classes take on a different meaning (to me) -- they're just a blueprint, and don't represent any concrete type (a program never actually runs a generic type, only specializations, even if some bytecode/machine code can be shared). Once someone instantiates a generic with some type, then to me that's a distinct type (i.e. Foo and Foo are two different closed types, who happen to share the same generic definition). Also, once you allow declaring static fields of the generic type, then it's a bit clearer that Foo and Foo are distinct types and don't share the same static field, right? In that case, it seems more natural to "unify" this and say that all static fields, irrespective of their type, belong to the concrete type and not the generic type. I sympathize with trying to preserve backwards compatibility and designing within the confines of an existing mature language. However, it may be the greater good to possibly break away from legacy and advance the language with a forward-looking hat on, rather than dragging the historical elephant behind forever. It's a hard problem though ... On Mon, Oct 13, 2014 at 6:38 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Interesting discussion, although I wonder how much we are being biased by > how the current implementation works; let's imagine a world where type > specialization is not needed - we can have a single erased/templating > format that suits all parameterizations (of course you'd need an expressive > enough instruction set) - if that's the case, you'll have a single *class > *generating multiple *types* with no need for specialization. Would that > change the perception of statics when it come to generic classes? > > The key thing about generics is that they change the relation between > classes and types in a fundamental way - before JDK 5 for each class you'd > get one type (1:1). After JDK 5, one class can be instantiated to multiple > parameterized types (1:N). In the Java language, the word 'static' is > typically used to denote 'class'-wide properties. Think about locks - > locking on a static field F means locking on the class instance > representing the class defining F. I think the meaning of programs should > be preserved as much as possible before/after reification; it might seem > that, as primitive/values in generics were never allowed before, we have > more freedom here - but we must think about reference types in the back of > our head: do we really want to change the meaning of programs accessing > static fields on Foo vs. Foo ? > > Maurizio > > > On 13/10/14 20:20, Vitaly Davidovich wrote: > > Sure, I don't dismiss the historical aspect of this. However, I don't > necessarily think this should be a barrier if generics were to be reified > or specialization introduced. In that case, people should become aware of > what's happening with their static fields, and once they do, I don't think > they'll find it unintuitive given the new context. I think it's intuitive > to think of generic types (in a specialized/reified world) as > recipes/templates/"super macros" for concrete instantiations, and given > that, it makes sense (to me, at least) that the static fields are > replicated across the actual instantiations. > > On Mon, Oct 13, 2014 at 3:13 PM, Brian Goetz wrote: > > > As a user, I would *not* expect that there's just one fooCount field for > > all Foo instances. > > > Except that's how generics have worked in Java since 2004. Do you propose > that existing generic code with statics should change how it behaves? Or > are you suggesting that the existing behavior is also counterintuitive? > > > > From brian.goetz at oracle.com Tue Oct 14 01:21:39 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Oct 2014 21:21:39 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> <543C547B.5000809@oracle.com> Message-ID: <543C7AA3.8060206@oracle.com> I think you're making some assumptions about the goals here which are not accurate. You talk about "reification" like we're going to drop existing generics and adopt something like what C# did. That's not what's going on. (The elephant analogy is apt, since it seems that everyone has their own idea of what reified generics means... :) So, to be clear, reified generics isn't the primary goal here. (It so happens that specialized generics *are* reified, but that's a side-effect of the implementation strategy rather than the goal, and actually a semi-problematic one at that.) On 10/13/2014 7:04 PM, Vitaly Davidovich wrote: > The issue is that since java doesn't reify generics, users know that > there's just one type. No, there's many types, there's one *class*. The Java language has a type system, and the VM has a type system, and they're different. Under specialized generics, there is one class for all reference types (same game as before), and one specialization for each primitive/value instantiation. (This is not unlike what C# does under the hood; it compiles one set of native code for erased references, and one set per unique struct instantiation.) > My argument is that if there's reification, then > generic classes take on a different meaning (to me) There's nothing wrong with this argument if you were starting from a blank sheet of paper. You could define things to work however you want. But that's not what we're doing here; we're doing that in the context of Java having had erased generics for ten years (and people only recently wrapping their heads around how generics work.) We're not going to pull the rug out from under users like that. (Remember, even if we did try to do some sort of full blown reification, we'd *still* have to deal with erasure, as old classfiles that instantiate erased instances would have to keep working.) From david.holmes at oracle.com Tue Oct 14 04:12:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Oct 2014 14:12:48 +1000 Subject: Static fields in specialized classes In-Reply-To: <543C17C3.50104@oracle.com> References: <543C17C3.50104@oracle.com> Message-ID: <543CA2C0.9030609@oracle.com> On 14/10/2014 4:19 AM, Brian Goetz wrote: > We stumbled across a few issues regarding static fields in specialized > classes in the prototype. There seems to be a reasonably > straightforward solution but it does touch quite a number of things. > > Consider: > > class Foo { > public final static int x = System.currentTimeMillis(); > } > > Regardless of whether our implementation is by specialization or erasure > (or both), logically there is just *one* field 'x' for any instantiation > Foo. Having read the rest of the thread the premise here is that there is only one generic class regardless of how many generic types; and as statics are associated with a class it follows there is one static field shared across all those types. It's a sound, compatible view of the world. Of course people may ask for a per-specialization "static" field mechanism. Does this mean that for each specialization getClass()/.class return different Class objects (ie a Class object per type)? I'll assume yes. > If we take a naive approach to specialization, where we just copy > members from Foo to Foo during specialization, we end up > with two 'x' fields (wrong). So the specializer should strip out static > members during specialization. (If the base class has static members, > we also need to add back a clinit member in Foo to force loading of > base Foo, to ensure that all instantiations of Foo have a > consistent view of Foo's statics.) So then we're done. Seems to be implementation detail. > Except for access through instances (yechh). Here, the compiler needs > to rewrite any references to f.x (where f is an instance of a > specialization of Foo) to Foo.x, and we're done. Didn't we deprecate that yet? :) Arguably javac should do this regardless of specialization - though the JLS would have to specify the conversion to ensure all javac's comply. > Except for access control; if x is private, then we get an > IllegalAccessError on any references to x from within Foo to Foo.x. > Which means that Foo has to be loaded as if with a host class of > Foo. (Just as defineAnonymousClass supports a host class, classdynamic > will need to as well.) So then we're done. Is this an implementation issue? The access control rules can easily be updated to account for specializations and grant them access. > Except for reflection; reflection on Foo.class should still show > that it has the same static members as Foo, and in fact they *are* the > same static members. So then we're done. Distinct Class objects seem problematic in this regard. The conceptual model of statics being like instance fields of the associated Class object breaks down here. A Class object is not really a "class" object but a "type" object. > Except for MH lookup. Will need to fix that up too. > > Any others? JVM TI and any other VM based introspection mechanisms. David From vitalyd at gmail.com Tue Oct 14 12:50:07 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 14 Oct 2014 08:50:07 -0400 Subject: Static fields in specialized classes In-Reply-To: <543C7AA3.8060206@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> <543C547B.5000809@oracle.com> <543C7AA3.8060206@oracle.com> Message-ID: "Under specialized generics, there is one class for all reference types (same game as before), and one specialization for each primitive/value instantiation. (This is not unlike what C# does under the hood; it compiles one set of native code for erased references, and one set per unique struct instantiation.)" In the CLR, the fact that structs get unique native code is a design issue/restriction due to variable size of structs (refs are easy since they're all same size pointers). In theory, structs of equal layout could share machine code. How's this going to work for generic methods that are constrained to take an interface type and thus allow structs/value types to be passed in? Specifically, in .NET this allows avoiding boxing of struct arguments. Is generic method specialization going to address that? Will reflection allow introspection of generic types and provide information about the generic definition? Will it be possible to instantiate a generic type specialization via reflection/late-binding? Finally, there's a neat use case in .NET regarding generic types and static fields of that generic type. For example, there's a generic abstract class called Comparer. It has a property called Default, which returns a Comparer suitable for comparing T instances. Internally, it decides what comparer to use by inspecting aspects of T. The end result is you get a comparer that will avoid boxing of structs if T is a struct. Is something like that going to work in what you guys are thinking of? Sent from my phone On Oct 13, 2014 9:21 PM, "Brian Goetz" wrote: > I think you're making some assumptions about the goals here which are not > accurate. You talk about "reification" like we're going to drop existing > generics and adopt something like what C# did. That's not what's going on. > > (The elephant analogy is apt, since it seems that everyone has their own > idea of what reified generics means... :) > > So, to be clear, reified generics isn't the primary goal here. (It so > happens that specialized generics *are* reified, but that's a side-effect > of the implementation strategy rather than the goal, and actually a > semi-problematic one at that.) > > On 10/13/2014 7:04 PM, Vitaly Davidovich wrote: > >> The issue is that since java doesn't reify generics, users know that >> there's just one type. >> > > No, there's many types, there's one *class*. The Java language has a type > system, and the VM has a type system, and they're different. > > Under specialized generics, there is one class for all reference types > (same game as before), and one specialization for each primitive/value > instantiation. (This is not unlike what C# does under the hood; it > compiles one set of native code for erased references, and one set per > unique struct instantiation.) > > My argument is that if there's reification, then >> generic classes take on a different meaning (to me) >> > > There's nothing wrong with this argument if you were starting from a blank > sheet of paper. You could define things to work however you want. But > that's not what we're doing here; we're doing that in the context of Java > having had erased generics for ten years (and people only recently wrapping > their heads around how generics work.) We're not going to pull the rug out > from under users like that. > > (Remember, even if we did try to do some sort of full blown reification, > we'd *still* have to deal with erasure, as old classfiles that instantiate > erased instances would have to keep working.) > > From maurizio.cimadamore at oracle.com Tue Oct 14 13:36:16 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 14 Oct 2014 13:36:16 +0000 Subject: hg: valhalla/valhalla/langtools: Tweak specializatoin logic to leave access to statics untouched. Message-ID: <201410141336.s9EDaGZb027781@aojmv0008> Changeset: c3de7848b921 Author: mcimadamore Date: 2014-10-14 14:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c3de7848b921 Tweak specializatoin logic to leave access to statics untouched. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java From brian.goetz at oracle.com Tue Oct 14 13:36:15 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Oct 2014 09:36:15 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> <543C547B.5000809@oracle.com> <543C7AA3.8060206@oracle.com> Message-ID: <543D26CF.7050800@oracle.com> > In the CLR, the fact that structs get unique native code is a design > issue/restriction due to variable size of structs (refs are easy since > they're all same size pointers). In theory, structs of equal layout > could share machine code. Its slightly more complicated than simply size -- you have to take into account whether the fields are refs or primitives as well (because the GC has to know where all the pointers are.) The minimal unit of sharing would be based on tuples of (n references, m bytes of non-references (modulo alignment requirements)). But we believe we have a path that will eventually get us to a higher degree of code sharing as well. > How's this going to work for generic methods that are constrained to > take an interface type and thus allow structs/value types to be passed > in? Specifically, in .NET this allows avoiding boxing of struct > arguments. Is generic method specialization going to address that? > > Will reflection allow introspection of generic types and provide > information about the generic definition? Will it be possible to > instantiate a generic type specialization via reflection/late-binding? All good questions; detailed answers will be answered in good time. Until then, the short answer is: if we couldn't avoid boxing, there's no point in doing specialization at all, and reflection support is part of doing language features. > Finally, there's a neat use case in .NET regarding generic types and > static fields of that generic type. For example, there's a generic > abstract class called Comparer. It has a property called Default, > which returns a Comparer suitable for comparing T instances. > Internally, it decides what comparer to use by inspecting aspects of T. > The end result is you get a comparer that will avoid boxing of structs > if T is a struct. Is something like that going to work in what you guys > are thinking of? Sure, it's a neat use case. (Does that make it a requirement? Absolutely not.) Note there's a difference between "can I write code with the effect as this C# code" and "can I write it exactly the same way as C#". I think the per-specialization static fields feature that you'd like is a massive loser. But the use case is valid, and I believe we'll get there by some other means. From maurizio.cimadamore at oracle.com Tue Oct 14 13:37:28 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 14 Oct 2014 13:37:28 +0000 Subject: hg: valhalla/valhalla/langtools: Add test for static access. Message-ID: <201410141337.s9EDbSNg027972@aojmv0008> Changeset: a93da9440dbc Author: mcimadamore Date: 2014-10-14 14:34 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a93da9440dbc Add test for static access. + test/tools/javac/valhalla/typespec/Statics01.java From vitalyd at gmail.com Tue Oct 14 14:29:01 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 14 Oct 2014 10:29:01 -0400 Subject: Static fields in specialized classes In-Reply-To: <543D26CF.7050800@oracle.com> References: <543C17C3.50104@oracle.com> <543C1E02.9010501@oracle.com> <543C2456.6090708@oracle.com> <543C547B.5000809@oracle.com> <543C7AA3.8060206@oracle.com> <543D26CF.7050800@oracle.com> Message-ID: Thanks Brian. I agree that the end effect is what's most important; I was using .NET as a concrete example since (a) it's a similar runtime/platform to the JVM, (b) I find it well-thought out and (c) I'm familiar with it. Looking forward to seeing what you guys come up with! On Tue, Oct 14, 2014 at 9:36 AM, Brian Goetz wrote: > In the CLR, the fact that structs get unique native code is a design >> issue/restriction due to variable size of structs (refs are easy since >> they're all same size pointers). In theory, structs of equal layout >> could share machine code. >> > > Its slightly more complicated than simply size -- you have to take into > account whether the fields are refs or primitives as well (because the GC > has to know where all the pointers are.) The minimal unit of sharing would > be based on tuples of (n references, m bytes of non-references (modulo > alignment requirements)). But we believe we have a path that will > eventually get us to a higher degree of code sharing as well. > > How's this going to work for generic methods that are constrained to >> take an interface type and thus allow structs/value types to be passed >> in? Specifically, in .NET this allows avoiding boxing of struct >> arguments. Is generic method specialization going to address that? >> >> Will reflection allow introspection of generic types and provide >> information about the generic definition? Will it be possible to >> instantiate a generic type specialization via reflection/late-binding? >> > > All good questions; detailed answers will be answered in good time. Until > then, the short answer is: if we couldn't avoid boxing, there's no point in > doing specialization at all, and reflection support is part of doing > language features. > > Finally, there's a neat use case in .NET regarding generic types and >> static fields of that generic type. For example, there's a generic >> abstract class called Comparer. It has a property called Default, >> which returns a Comparer suitable for comparing T instances. >> Internally, it decides what comparer to use by inspecting aspects of T. >> The end result is you get a comparer that will avoid boxing of structs >> if T is a struct. Is something like that going to work in what you guys >> are thinking of? >> > > Sure, it's a neat use case. (Does that make it a requirement? Absolutely > not.) Note there's a difference between "can I write code with the effect > as this C# code" and "can I write it exactly the same way as C#". I think > the per-specialization static fields feature that you'd like is a massive > loser. But the use case is valid, and I believe we'll get there by some > other means. > > From scolebourne at joda.org Tue Oct 14 14:46:33 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 14 Oct 2014 15:46:33 +0100 Subject: Static fields in specialized classes In-Reply-To: <543C17C3.50104@oracle.com> References: <543C17C3.50104@oracle.com> Message-ID: On 13 October 2014 19:19, Brian Goetz wrote: > Consider: > > class Foo { > public final static int x = System.currentTimeMillis(); > } > > Regardless of whether our implementation is by specialization or erasure (or > both), logically there is just *one* field 'x' for any instantiation Foo. Just to note that I support this view of the world. I think the alternatives would be surprising. > Except for access through instances (yechh). Here, the compiler needs to > rewrite any references to f.x (where f is an instance of a specialization of > Foo) to Foo.x, and we're done. There are a number of these edge cases in the Java language which are almost never used and which Java the language would be far better off without. Another is C style array locations, such as int splitAndParse[](String str). It seems entirely feasible to be more aggressive on these. Deprecate in 9 (with warnings) and remove in 10. Isn't it time to take out some of the garbage? Stephen From brian.goetz at oracle.com Tue Oct 14 15:05:25 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 14 Oct 2014 15:05:25 +0000 Subject: hg: valhalla/valhalla/jdk: Strip static members during specialization; add back in that forces loading of base class Message-ID: <201410141505.s9EF5P9V015058@aojmv0008> Changeset: 8ad1693739bc Author: briangoetz Date: 2014-10-14 11:05 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8ad1693739bc Strip static members during specialization; add back in that forces loading of base class ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! test/valhalla/test/valhalla/specializer/SpecializationMetadataTest.java + test/valhalla/test/valhalla/specializer/StaticMemberTest.java From brian.goetz at oracle.com Tue Oct 14 18:13:13 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Oct 2014 14:13:13 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> Message-ID: <543D67B9.1000802@oracle.com> OK, now that this is settled... can I get some input on the original question? Can anyone else thing of code that will need to be adjusted to support this view of the world? On 10/14/2014 10:46 AM, Stephen Colebourne wrote: > On 13 October 2014 19:19, Brian Goetz wrote: >> Consider: >> >> class Foo { >> public final static int x = System.currentTimeMillis(); >> } >> >> Regardless of whether our implementation is by specialization or erasure (or >> both), logically there is just *one* field 'x' for any instantiation Foo. > > Just to note that I support this view of the world. I think the > alternatives would be surprising. From vitalyd at gmail.com Tue Oct 14 18:33:17 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 14 Oct 2014 14:33:17 -0400 Subject: Static fields in specialized classes In-Reply-To: <543D67B9.1000802@oracle.com> References: <543C17C3.50104@oracle.com> <543D67B9.1000802@oracle.com> Message-ID: Runtime bytecode enhancement/weaving? Non javac bytecode generators? Did you see David Holmes' reply (JVMTI)? Sent from my phone On Oct 14, 2014 2:14 PM, "Brian Goetz" wrote: > OK, now that this is settled... can I get some input on the original > question? Can anyone else thing of code that will need to be adjusted to > support this view of the world? > > On 10/14/2014 10:46 AM, Stephen Colebourne wrote: > >> On 13 October 2014 19:19, Brian Goetz wrote: >> >>> Consider: >>> >>> class Foo { >>> public final static int x = System.currentTimeMillis(); >>> } >>> >>> Regardless of whether our implementation is by specialization or erasure >>> (or >>> both), logically there is just *one* field 'x' for any instantiation >>> Foo. >>> >> >> Just to note that I support this view of the world. I think the >> alternatives would be surprising. >> > From paul.sandoz at oracle.com Tue Oct 14 21:08:43 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Oct 2014 23:08:43 +0200 Subject: Static fields in specialized classes In-Reply-To: <543D67B9.1000802@oracle.com> References: <543C17C3.50104@oracle.com> <543D67B9.1000802@oracle.com> Message-ID: <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> On Oct 14, 2014, at 8:13 PM, Brian Goetz wrote: > OK, now that this is settled... can I get some input on the original question? Can anyone else thing of code that will need to be adjusted to support this view of the world? > Quick thoughts, need to think more thoroughly: - could be some implications for Unsafe access, there is a shared memory location but the receivers might be different. The easy way out is to say "this is unsafe! you need to check beforehand what receiver to use for such cases". - care might need to be taken with class initlization, static access should trigger initialisation before that access occurs but does this mean both Foo and Foo should be initialized if access occurs from the latter? (not sure if you already have this aspect covered) Paul. > On 10/14/2014 10:46 AM, Stephen Colebourne wrote: >> On 13 October 2014 19:19, Brian Goetz wrote: >>> Consider: >>> >>> class Foo { >>> public final static int x = System.currentTimeMillis(); >>> } >>> >>> Regardless of whether our implementation is by specialization or erasure (or >>> both), logically there is just *one* field 'x' for any instantiation Foo. >> >> Just to note that I support this view of the world. I think the >> alternatives would be surprising. From brian.goetz at oracle.com Tue Oct 14 21:45:12 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Oct 2014 17:45:12 -0400 Subject: Static fields in specialized classes In-Reply-To: <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> References: <543C17C3.50104@oracle.com> <543D67B9.1000802@oracle.com> <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> Message-ID: <543D9968.10400@oracle.com> > - care might need to be taken with class initlization, static access > should trigger initialisation before that access occurs but does this > mean both Foo and Foo should be initialized if access occurs > from the latter? (not sure if you already have this aspect covered) I think we have this one covered. The compiler and specializer cooperate to have this effect. - All declarations of static members (fields and methods, including ) are stripped out during specialization. So the static members exist only on the template (base) class. - All references to static members (whether through classes or through instances) are rewritten to directly reference the template class. - Specialized classes acquire a that does "LDC template.class", idempotently forcing the template class to be initialized if it is not already. This is all implemented in the prototype as of today. From scolebourne at joda.org Tue Oct 14 22:16:33 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 14 Oct 2014 23:16:33 +0100 Subject: Static fields in specialized classes In-Reply-To: <543C17C3.50104@oracle.com> References: <543C17C3.50104@oracle.com> Message-ID: On 13 October 2014 19:19, Brian Goetz wrote: > Except for reflection; reflection on Foo.class should still show that > it has the same static members as Foo, and in fact they *are* the same > static members. So then we're done. The suggestion that there will be a Foo.class as well as a Foo.class is one that must have implications on logic in end user programs. Today, I can assume that if there is a method void process(Foo) then it cannot be overloaded, but I presume that the existence of Foo.class implies that you can overload now? void process(Foo) void process(Foo) My gut feeling is that this is undesirable and should be disallowed, and that perhaps we shouldn't even be able to observe Foo.class at all. After all, if specialization is intended to be viewed primarily as an implementation detail, just like erasure, then shouldn't it be directly observable in Java code based on Class just like erasure. ie a Class remains as a single template, with a Type remaining as the type system type, and perhaps with a third intermediate form added between the two - "Specialism" or some such name). In other words, while the Java language/library changes may be expressed by some improvements to reflection, I'd be concerned about the many implemented algorithms based on reflection. Stephen From vitalyd at gmail.com Tue Oct 14 22:57:33 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 14 Oct 2014 18:57:33 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> Message-ID: Why should this be disallowed in the language (whether it's a good idea to write that as a developer is a different story)? Suppose you have a non-generic class with that generic method, but then you also have some specialization for Foo (again, good or bad idea from design standpoint aside). If we're not erasing generics anymore, then I don't see anything unsound from a type system perspective (overload resolution would pick the most precise, favoring non-generic methods over generic). Also, this wouldn't break any existing code since that's not possible today with erasure, so would be safe from a backcompat viewpoint. As a slight tangent to this, it would be nice if we can finally implement the same generic interface on a class with different types, e.g.: interface Message {} class Message1 implements Message {} class Message2 implements Message{} interface Handler { void handle(M msg); } class MyHandler implements Handler, Handler { void handle(Message1 m) {} void handle(Message2 m) {} } On Tue, Oct 14, 2014 at 6:16 PM, Stephen Colebourne wrote: > On 13 October 2014 19:19, Brian Goetz wrote: > > Except for reflection; reflection on Foo.class should still show > that > > it has the same static members as Foo, and in fact they *are* the same > > static members. So then we're done. > > The suggestion that there will be a Foo.class as well as a > Foo.class is one that must have implications on logic in end user > programs. Today, I can assume that if there is a method > > void process(Foo) > > then it cannot be overloaded, but I presume that the existence of > Foo.class implies that you can overload now? > > void process(Foo) > void process(Foo) > > My gut feeling is that this is undesirable and should be disallowed, > and that perhaps we shouldn't even be able to observe Foo.class > at all. > > After all, if specialization is intended to be viewed primarily as an > implementation detail, just like erasure, then shouldn't it be > directly observable in Java code based on Class just like erasure. ie > a Class remains as a single template, with a Type remaining as the > type system type, and perhaps with a third intermediate form added > between the two - "Specialism" or some such name). > > In other words, while the Java language/library changes may be > expressed by some improvements to reflection, I'd be concerned about > the many implemented algorithms based on reflection. > > Stephen > From brian.goetz at oracle.com Tue Oct 14 23:59:42 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Oct 2014 19:59:42 -0400 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> Message-ID: <543DB8EE.6070801@oracle.com> > My gut feeling is that this is undesirable and should be disallowed, > and that perhaps we shouldn't even be able to observe Foo.class > at all. If you think about the problem a little more, I think you'll find that this is wishful thinking. (But of course, you're free to have a gut feeling without having thought about it at all.) > After all, if specialization is intended to be viewed primarily as an > implementation detail It is an implementation detail in the same sense that erasure is; that generics are implemented by erasure almost certainly leaks into the user's perception too. (Erasure is why you can't have Foo.class, for example. Among many other things that the user has to pay attention to.) class Foo { T get() { ... } } Consider the members of various instantiations of Foo. The signature of get() in Foo is "String get()", but the signature of get() in Foo is "int get()". The erasure of the first is "Object get()"; the erasure of the second is "int get()". While all erased reference instantiations can be implemented by the same class, the primitive/value instantiations cannot be. Similarly, Foo can't extend Foo (because that really means Foo, and has to for compatibility reasons), nor can it extend raw Foo. (Which is fine; raw types exist solely to support migration from ungenerified codebases to generified ones.) We could hide the existence of List.class, but that would just make life harder for users, who would then have to jump through bigger hoops to reflect over the members of List (which are different from the members of List, even after erasure.) > In other words, while the Java language/library changes may be > expressed by some improvements to reflection, I'd be concerned about > the many implemented algorithms based on reflection. It is of course reasonable to be concerned. Stay tuned and see if your concerns are addressed. From benlewisj at gmail.com Wed Oct 15 08:30:36 2014 From: benlewisj at gmail.com (Ben Lewis) Date: Wed, 15 Oct 2014 21:30:36 +1300 Subject: Static fields in specialized classes In-Reply-To: <543DB8EE.6070801@oracle.com> References: <543C17C3.50104@oracle.com> <543DB8EE.6070801@oracle.com> Message-ID: I think having Foo.class and Foo.class be different is a mistake. class Person{} class Employee extends Bar{ //lots of other stuff irrelevant to T T getId(){ ? } } Person p1=new Employee(); Person p2=new Employee(); As I understand it p1.class==Employee.class;//true p2.class==Employee.class;//false p1 instanceof Employee;//true p2 instanceof Employee;//false How to determine b2 comes from ?source class? Employee? This will cause bugs in situations where the programmer expects how the class hierarchy acts now rather than changing it to where specialisation having a different class. This would also mean migrating to will cause backward compatibility issues. For example if(p instanceof Employee){ //do something }else{ //do something else } if written before specialisations It would do as expected but after and if p=new Employee() it would execute the else block not as expected when the code is written. On Wed, Oct 15, 2014 at 12:59 PM, Brian Goetz wrote: > My gut feeling is that this is undesirable and should be disallowed, >> and that perhaps we shouldn't even be able to observe Foo.class >> at all. >> > > If you think about the problem a little more, I think you'll find that > this is wishful thinking. (But of course, you're free to have a gut > feeling without having thought about it at all.) > > After all, if specialization is intended to be viewed primarily as an >> implementation detail >> > > It is an implementation detail in the same sense that erasure is; that > generics are implemented by erasure almost certainly leaks into the user's > perception too. (Erasure is why you can't have Foo.class, for > example. Among many other things that the user has to pay attention to.) > > class Foo { > T get() { ... } > } > > Consider the members of various instantiations of Foo. > > The signature of get() in Foo is "String get()", but the signature > of get() in Foo is "int get()". The erasure of the first is "Object > get()"; the erasure of the second is "int get()". While all erased > reference instantiations can be implemented by the same class, the > primitive/value instantiations cannot be. > > Similarly, Foo can't extend Foo (because that really means Foo extends Object>, and has to for compatibility reasons), nor can it extend > raw Foo. (Which is fine; raw types exist solely to support migration from > ungenerified codebases to generified ones.) > > We could hide the existence of List.class, but that would just make > life harder for users, who would then have to jump through bigger hoops to > reflect over the members of List (which are different from the members > of List, even after erasure.) > > In other words, while the Java language/library changes may be >> expressed by some improvements to reflection, I'd be concerned about >> the many implemented algorithms based on reflection. >> > > It is of course reasonable to be concerned. Stay tuned and see if your > concerns are addressed. > From paul.sandoz at oracle.com Wed Oct 15 10:22:24 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 15 Oct 2014 12:22:24 +0200 Subject: Static fields in specialized classes In-Reply-To: <543D9968.10400@oracle.com> References: <543C17C3.50104@oracle.com> <543D67B9.1000802@oracle.com> <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> <543D9968.10400@oracle.com> Message-ID: On Oct 14, 2014, at 11:45 PM, Brian Goetz wrote: >> - care might need to be taken with class initlization, static access >> should trigger initialisation before that access occurs but does this >> mean both Foo and Foo should be initialized if access occurs >> from the latter? (not sure if you already have this aspect covered) > > I think we have this one covered. The compiler and specializer cooperate to have this effect. > > - All declarations of static members (fields and methods, including ) are stripped out during specialization. So the static members exist only on the template (base) class. > > - All references to static members (whether through classes or through instances) are rewritten to directly reference the template class. > > - Specialized classes acquire a that does "LDC template.class", idempotently forcing the template class to be initialized if it is not already. > I am not sure an LDC is sufficient to guarantee initialization of the template class. See example program below. It may be necessary to invoke UNSAFE.ensureClassInitialized after the LDC of the class. If thats the case we could stuff a global UNSAFE instance in the constant pool when anonymously defining the class (much like direct method handles to fields). Paul. import sun.misc.Unsafe; import java.lang.reflect.Field; public class STest { private static final Unsafe UNSAFE; static { try { Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe"); unsafeField.setAccessible(true); UNSAFE = (Unsafe) unsafeField.get(null); } catch (Exception e) { throw new AssertionError(e); } } static class Foo { static { System.out.println("INIT FOO"); } static int x; T get(T t) { return t; } } static class A { static { System.out.println("INIT A"); } } static class B { static { // This is not sufficient to initialize A Class c = A.class; // Use Unsafe to ensure initialization of A // UNSAFE.ensureClassInitialized(c); System.out.println("INIT B"); } } public static void main(String[] args) { System.out.printf("Should %s be initialized? %s\n", Foo.class, UNSAFE.shouldBeInitialized(Foo.class)); System.out.println("BEFORE SPECIALIZATION"); Foo fi = new Foo<>(); System.out.println("AFTER SPECIALIZATION"); System.out.printf("Should %s be initialized? %s\n", Foo.class, UNSAFE.shouldBeInitialized(Foo.class)); System.out.printf("Should %s be initialized? %s\n", fi.getClass(), UNSAFE.shouldBeInitialized(fi.getClass())); System.out.println("BEFORE fi.get(1)"); System.out.println(fi.get(1)); System.out.println("AFTER fi.get(1)"); System.out.println("BEFORE Foo.x"); System.out.println(Foo.x); System.out.println("AFTER Foo.x"); B b = new B(); } } From forax at univ-mlv.fr Wed Oct 15 11:14:05 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 15 Oct 2014 13:14:05 +0200 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> <543D67B9.1000802@oracle.com> <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> <543D9968.10400@oracle.com> Message-ID: <543E56FD.2000703@univ-mlv.fr> On 10/15/2014 12:22 PM, Paul Sandoz wrote: > On Oct 14, 2014, at 11:45 PM, Brian Goetz wrote: > >>> - care might need to be taken with class initlization, static access >>> should trigger initialisation before that access occurs but does this >>> mean both Foo and Foo should be initialized if access occurs >>> from the latter? (not sure if you already have this aspect covered) >> I think we have this one covered. The compiler and specializer cooperate to have this effect. >> >> - All declarations of static members (fields and methods, including ) are stripped out during specialization. So the static members exist only on the template (base) class. >> >> - All references to static members (whether through classes or through instances) are rewritten to directly reference the template class. >> >> - Specialized classes acquire a that does "LDC template.class", idempotently forcing the template class to be initialized if it is not already. >> > I am not sure an LDC is sufficient to guarantee initialization of the template class. See example program below. No, it doesn't. LDC do load the class but the VM is not required to trigger the class initialisation. > > It may be necessary to invoke UNSAFE.ensureClassInitialized after the LDC of the class. > > If thats the case we could stuff a global UNSAFE instance in the constant pool when anonymously defining the class (much like direct method handles to fields). or to call an empty static method generated on purpose by javac. > > Paul. R?mi From maurizio.cimadamore at oracle.com Wed Oct 15 13:00:46 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:00:46 +0000 Subject: hg: valhalla/valhalla: 71 new changesets Message-ID: <201410151300.s9FD0qYL027851@aojmv0008> Changeset: 57651e8cf67b Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/57651e8cf67b Added tag jdk9-b26 for changeset d3ec8d048e6c ! .hgtags Changeset: 73274a451ccb Author: lana Date: 2014-08-11 09:25 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/73274a451ccb Merge Changeset: c72d6edec4cf Author: chegar Date: 2014-08-18 10:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c72d6edec4cf Merge Changeset: 13255d60e919 Author: erikj Date: 2014-08-19 13:43 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/13255d60e919 8022177: Windows/MSYS builds broken Reviewed-by: tbell, erikj, simonis Contributed-by: volker.simonis at gmail.com, erik.joelsson at oracle.com ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain_windows.m4 ! make/common/NativeCompilation.gmk Changeset: 2870f66fe00e Author: mchung Date: 2014-08-19 19:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2870f66fe00e 8055497: [infra] build failure when building bootcycle image Reviewed-by: naoto ! make/Main.gmk Changeset: 2bfa8c391bdc Author: erikj Date: 2014-08-20 14:11 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2bfa8c391bdc 8055405: JDK 9 build started failing on ja_JP.UTF-8 locale due to mapping error (encoding=ascii). Reviewed-by: ihse ! make/common/IdlCompilation.gmk Changeset: ea2f7981236f Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ea2f7981236f Merge Changeset: 26da7905a6b2 Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/26da7905a6b2 Added tag jdk9-b28 for changeset ea2f7981236f ! .hgtags Changeset: dbb964d72f25 Author: erikj Date: 2014-08-21 11:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/dbb964d72f25 8055188: General cleanup of minor issues from source restructure Reviewed-by: tbell ! make/CompileJavaModules.gmk ! make/Main.gmk - make/common/SetupJava.gmk + make/common/SetupJavaCompilers.gmk Changeset: 70e378877c6a Author: erikj Date: 2014-08-21 12:22 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/70e378877c6a 8055095: Improve "do nothing" incremental build performance after modularized source code integration Reviewed-by: tbell ! make/CompileJavaModules.gmk ! make/Main.gmk ! make/MakeHelpers.gmk ! make/common/MakeBase.gmk + make/common/Modules.gmk Changeset: d9edec389373 Author: mduigou Date: 2014-08-21 10:22 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d9edec389373 8055772: get_source.sh : version check assumes English localization Reviewed-by: mduigou, tbell Contributed-by: bitterfoxc at gmail.com ! get_source.sh Changeset: f91649eb1db2 Author: mduigou Date: 2014-08-21 10:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f91649eb1db2 8055331: cleaner handling of sub-process non-zero exit result. Reviewed-by: tbell ! common/bin/hgforest.sh Changeset: 274543b2de27 Author: erikj Date: 2014-08-22 11:51 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/274543b2de27 8055096: Remove explicit mx flag from javadoc command line Reviewed-by: tbell, mduigou ! make/Javadoc.gmk Changeset: ba1bab36d1bf Author: ctornqvi Date: 2014-08-18 14:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ba1bab36d1bf 8032999: [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job Summary: JPRT will now run most of the tests in /runtime Reviewed-by: dcubed, mseledtsov, zgu, mikael ! make/jprt.properties Changeset: 27c26438e4c8 Author: sspitsyn Date: 2014-08-20 17:05 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/27c26438e4c8 Merge Changeset: 446472cfcca8 Author: anoll Date: 2014-08-05 09:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/446472cfcca8 8054013: run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx Summary: Modify hotspot/make/jprt.properties and make/jprt.properties on the top level to add/remove the relevant platforms. Reviewed-by: kvn, roland Contributed-by: Zoltan Majo ! make/jprt.properties Changeset: b86c13b9a7df Author: mduigou Date: 2014-08-13 19:39 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b86c13b9a7df 8047952: Remove FORTIFY_SOURCE from fastdebug and slowdebug builds Reviewed-by: dholmes ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 0736f13c91bd Author: kvn Date: 2014-08-21 15:37 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0736f13c91bd Merge ! common/autoconf/generated-configure.sh ! make/jprt.properties Changeset: b953531f403d Author: amurillo Date: 2014-08-22 10:03 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b953531f403d Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! make/jprt.properties Changeset: a423abd014f7 Author: mchung Date: 2014-08-26 14:35 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a423abd014f7 8055230: Rename attach provider implementation class be platform neutral Reviewed-by: alanb, chegar, dfuchs, dholmes, erikj, sla ! make/CompileJavaModules.gmk Changeset: 3c994e1648ac Author: erikj Date: 2014-08-27 10:59 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3c994e1648ac 8056064: Fix corba locale build problem on windows Reviewed-by: alanb, tbell ! make/common/IdlCompilation.gmk Changeset: 1823df83c30e Author: erikj Date: 2014-08-27 11:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1823df83c30e 8056062: Additional minor cleanups from source restructure build changes Reviewed-by: alanb, tbell ! Makefile ! make/Main.gmk Changeset: 0ceccf7b30b2 Author: erikj Date: 2014-08-27 11:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0ceccf7b30b2 8055922: Work around sjavac limitation with public api tracking cross modules Reviewed-by: ihse ! make/common/JavaCompilation.gmk Changeset: 2a1d4d3e8c8e Author: simonis Date: 2014-08-29 12:02 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2a1d4d3e8c8e 8056246: Fix AIX build after the Modular Source Code change 8054834 Reviewed-by: erikj, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: e0a080fd4047 Author: erikj Date: 2014-08-29 13:30 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e0a080fd4047 8014510: Fix sjavac on all platforms in jprt Reviewed-by: ihse ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh Changeset: 3736cf40d962 Author: mchung Date: 2014-08-29 10:46 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3736cf40d962 8055856: checkdeps build target doesn't work for cross-compilation builds 8056113: [build] tools.jar missing modules.xml Reviewed-by: ihse, erikj + make/CheckModules.gmk ! make/Main.gmk Changeset: 9e6581aeda38 Author: lana Date: 2014-08-29 11:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9e6581aeda38 Merge Changeset: 44a5f9d70460 Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/44a5f9d70460 Added tag jdk9-b29 for changeset 9e6581aeda38 ! .hgtags Changeset: 0610b52412cf Author: ihse Date: 2014-09-01 10:39 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0610b52412cf 8027627: Don't hardcode bash path in LOG=trace Reviewed-by: erikj, tbell Contributed-by: Dmitry Samersoff ! make/common/MakeBase.gmk Changeset: d6cb4cea9c54 Author: prr Date: 2014-08-22 11:00 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d6cb4cea9c54 8039271: CMM profile files (cmm/*) should not be in ${java.home}/lib Reviewed-by: bae, mchung, erikj ! make/CompileJavaModules.gmk Changeset: b3e42a2a9619 Author: prr Date: 2014-09-02 11:21 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b3e42a2a9619 Merge ! make/CompileJavaModules.gmk Changeset: ce36ddb6dc61 Author: erikj Date: 2014-09-03 14:10 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ce36ddb6dc61 8057132: Build fails if PROFILE is set in the environment Reviewed-by: ihse, dholmes, fparain ! make/Main.gmk Changeset: 36e9bc875325 Author: lana Date: 2014-09-04 14:44 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/36e9bc875325 Merge Changeset: 65f52e02bc18 Author: katleman Date: 2014-09-11 09:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/65f52e02bc18 Added tag jdk9-b30 for changeset 36e9bc875325 ! .hgtags Changeset: dc29cb072e8a Author: erikj Date: 2014-09-05 12:42 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/dc29cb072e8a 8057537: Serialize reconfigure and fix make clean-foo foo Reviewed-by: dholmes, ihse, tbell ! Makefile ! make/Main.gmk Changeset: 16f1b2409462 Author: ihse Date: 2014-09-09 15:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/16f1b2409462 8057125: The fix for JDK-8027627 was incomplete: Don't hardcode bash anywhere. Reviewed-by: erikj ! make/common/MakeBase.gmk Changeset: 5d7de212359d Author: simonis Date: 2014-09-09 17:42 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5d7de212359d 8057538: Build the freetype library during configure on Windows Reviewed-by: erikj, ihse ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: fae1eb99785e Author: coffeys Date: 2014-09-10 16:13 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fae1eb99785e 8057813: Alterations to jdk_security3 test target Reviewed-by: mullan, wetmore, xuelei ! make/jprt.properties Changeset: edbc7981f3be Author: mduigou Date: 2014-09-10 12:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/edbc7981f3be 8056195: Add CUSTOM_SUMMARY_AND_WARNINGS_HOOK Reviewed-by: ihse, erikj ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh Changeset: 9b44369c5737 Author: mchung Date: 2014-09-10 17:32 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9b44369c5737 8057627: Add org.w3c.dom.ranges and org.w3c.dom.traversal as exported API in modules.xml Reviewed-by: alanb ! modules.xml Changeset: 7047a1fd4aa8 Author: lana Date: 2014-09-10 19:36 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7047a1fd4aa8 Merge Changeset: a1a2bb537718 Author: chegar Date: 2014-09-11 10:29 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a1a2bb537718 8058117: Missing jdk.deploy.osx from modules.xml Reviewed-by: alanb, mchung ! modules.xml Changeset: 69a84c16d9c2 Author: lana Date: 2014-09-11 14:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/69a84c16d9c2 Merge Changeset: 9918cd2de40d Author: katleman Date: 2014-09-17 22:55 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9918cd2de40d Added tag jdk9-b31 for changeset 69a84c16d9c2 ! .hgtags Changeset: 34df46455488 Author: lancea Date: 2014-09-12 17:46 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/34df46455488 8058366: Export sun.misc to java.sql Reviewed-by: mchung ! modules.xml Changeset: a3ee36412163 Author: ehelin Date: 2014-09-15 16:30 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a3ee36412163 8058317: Top-level Makefiles uses deprecated target jvmg in HotSpot Makefiles Reviewed-by: erikj, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 96de7aa61b7e Author: mchung Date: 2014-09-15 12:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/96de7aa61b7e 8058367: Add verify-modules target to the default and images target Reviewed-by: alanb, erikj, ihse, prr ! make/Main.gmk Changeset: 980f315286b9 Author: erikj Date: 2014-09-16 12:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/980f315286b9 8058118: Generate modules.list during the build Reviewed-by: alanb, ihse, tbell, mchung ! Makefile ! common/autoconf/spec.gmk.in ! make/Main.gmk ! make/common/Modules.gmk ! make/common/SetupJavaCompilers.gmk - make/common/modules.list ! modules.xml Changeset: 33968ec4cc68 Author: erikj Date: 2014-08-28 11:58 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/33968ec4cc68 8056053: Disable HOTSPOT_BUILD_JOBS when building with configure Reviewed-by: dholmes, ihse, dcubed ! common/autoconf/hotspot-spec.gmk.in ! make/HotspotWrapper.gmk Changeset: fac17bf59030 Author: amurillo Date: 2014-09-12 13:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fac17bf59030 Merge Changeset: 2556d0c2976a Author: amurillo Date: 2014-09-13 14:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2556d0c2976a Merge Changeset: 1540bfaa0606 Author: amurillo Date: 2014-09-16 08:04 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1540bfaa0606 Merge Changeset: d1d2ca914d49 Author: weijun Date: 2014-09-17 13:55 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d1d2ca914d49 8056141: Move com.sun.security.jgss into a new module Reviewed-by: alanb, chegar, mchung ! common/bin/unshuffle_list.txt ! modules.xml Changeset: 7e3512dae8e0 Author: lana Date: 2014-09-18 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7e3512dae8e0 Merge - make/common/modules.list Changeset: e1e5dd0de2e8 Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e1e5dd0de2e8 Added tag jdk9-b32 for changeset 7e3512dae8e0 ! .hgtags Changeset: 0937ce5890bc Author: erikj Date: 2014-09-19 11:53 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0937ce5890bc 8058797: Building with sjavac broken after JDK-8058118 Reviewed-by: ihse ! make/common/JavaCompilation.gmk ! make/common/Modules.gmk Changeset: d289c41136b9 Author: erikj Date: 2014-09-23 07:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d289c41136b9 8047933: Race between jdk/make/scripts/genExceptions.sh and com.sun.tools.javadoc.Main Reviewed-by: ihse, tbell ! make/Main.gmk Changeset: 7feeff170f81 Author: tbell Date: 2014-09-23 07:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7feeff170f81 Merge ! make/Main.gmk - make/common/modules.list Changeset: 654b0f026152 Author: igerasim Date: 2014-09-25 21:16 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/654b0f026152 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout Reviewed-by: dfuchs, chegar ! common/bin/unshuffle_patch.sh Changeset: 924b0ce4a167 Author: prr Date: 2014-09-19 09:42 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/924b0ce4a167 8056216: Remove "sun" directory layer from libawt and common Reviewed-by: erikj, ihse, coffeys ! common/bin/unshuffle_list.txt Changeset: ee6759334331 Author: prr Date: 2014-09-19 11:19 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ee6759334331 Merge ! common/bin/unshuffle_list.txt - make/common/modules.list Changeset: 555f3152c254 Author: prr Date: 2014-09-25 14:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/555f3152c254 Merge Changeset: e4ba01b726e2 Author: lana Date: 2014-09-25 16:19 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e4ba01b726e2 Merge Changeset: 742af6ac75e1 Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/742af6ac75e1 Added tag jdk9-b33 for changeset e4ba01b726e2 ! .hgtags Changeset: d9a01c3a983d Author: weijun Date: 2014-09-30 13:26 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d9a01c3a983d 8058657: Add @jdk.Exported to com.sun.jarsigner APIs Reviewed-by: alanb, mchung ! modules.xml Changeset: 36d6ab4de4db Author: sla Date: 2014-09-22 20:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/36d6ab4de4db 8058863: jdk9/hs-comp fails in jprt with "-testset hotspot" from top-level Reviewed-by: kvn ! make/jprt.properties Changeset: 89e2b423f537 Author: amurillo Date: 2014-09-26 01:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/89e2b423f537 Merge Changeset: ee584a8ce1f0 Author: amurillo Date: 2014-09-30 08:39 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ee584a8ce1f0 Merge Changeset: 087b23f35631 Author: lana Date: 2014-10-03 12:10 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/087b23f35631 Merge Changeset: eab699e0adc0 Author: katleman Date: 2014-10-09 11:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/eab699e0adc0 Added tag jdk9-b34 for changeset 087b23f35631 ! .hgtags Changeset: 609465a9f324 Author: mcimadamore Date: 2014-10-15 10:57 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/609465a9f324 merge with jdk9-b34 ! make/common/SetupJavaCompilers.gmk < make/common/SetupJava.gmk - make/common/modules.list From maurizio.cimadamore at oracle.com Wed Oct 15 13:01:45 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:01:45 +0000 Subject: hg: valhalla/valhalla/corba: 18 new changesets Message-ID: <201410151301.s9FD1jhR028055@aojmv0008> Changeset: 559dff17e7cc Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/559dff17e7cc Added tag jdk9-b26 for changeset 6c777df597bb ! .hgtags Changeset: dec99dfecb3f Author: lana Date: 2014-08-11 09:25 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/dec99dfecb3f Merge Changeset: 87987d1c767f Author: msheppar Date: 2014-08-11 21:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/87987d1c767f 8038861: [javadoc] broken links in org/omg/CORBA/FloatSeqHelper.html Summary: change cgi.omg.or to www.omg.org Reviewed-by: alanb ! src/share/classes/org/omg/CORBA/FloatSeqHelper.java Changeset: 4d704afddadd Author: chegar Date: 2014-08-18 10:07 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/4d704afddadd Merge ! src/java.corba/share/classes/org/omg/CORBA/FloatSeqHelper.java Changeset: a00b04ef067e Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/a00b04ef067e Merge Changeset: 85bac03b064e Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/85bac03b064e Added tag jdk9-b28 for changeset a00b04ef067e ! .hgtags Changeset: 1f5939bac4ae Author: erikj Date: 2014-08-27 10:59 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/1f5939bac4ae 8056064: Fix corba locale build problem on windows Reviewed-by: alanb, tbell ! make/GensrcCorba.gmk Changeset: 163a9cd806fd Author: lana Date: 2014-08-29 11:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/163a9cd806fd Merge Changeset: 98967ae6ae53 Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/98967ae6ae53 Added tag jdk9-b29 for changeset 163a9cd806fd ! .hgtags Changeset: 3aa9b894892f Author: katleman Date: 2014-09-11 09:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/3aa9b894892f Added tag jdk9-b30 for changeset 98967ae6ae53 ! .hgtags Changeset: 9baf79eda109 Author: wetmore Date: 2014-09-11 12:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/9baf79eda109 8058180: .hgignore should be updated with webrev in all repos Reviewed-by: jrose, katleman, jjg ! .hgignore Changeset: c432b80aadd0 Author: lana Date: 2014-09-11 14:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/c432b80aadd0 Merge Changeset: b5b139354630 Author: katleman Date: 2014-09-17 22:55 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/b5b139354630 Added tag jdk9-b31 for changeset c432b80aadd0 ! .hgtags Changeset: cfdac5887952 Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/cfdac5887952 Added tag jdk9-b32 for changeset b5b139354630 ! .hgtags Changeset: fa226c18e803 Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/fa226c18e803 Added tag jdk9-b33 for changeset cfdac5887952 ! .hgtags Changeset: 0e38044a6f85 Author: alanb Date: 2014-09-26 22:24 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/0e38044a6f85 8049389: Move orb.idl and ir.idl to JDK include directory Reviewed-by: erikj ! make/CompileCorba.gmk Changeset: 24a0bad5910f Author: lana Date: 2014-10-03 12:11 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/24a0bad5910f Merge Changeset: 9bc2dbd3dfb8 Author: katleman Date: 2014-10-09 11:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/9bc2dbd3dfb8 Added tag jdk9-b34 for changeset 24a0bad5910f ! .hgtags From maurizio.cimadamore at oracle.com Wed Oct 15 13:02:18 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:02:18 +0000 Subject: hg: valhalla/valhalla/jaxws: 17 new changesets Message-ID: <201410151302.s9FD2Il9028250@aojmv0008> Changeset: 2f11a520698c Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/2f11a520698c Added tag jdk9-b26 for changeset 9b43f3993b96 ! .hgtags Changeset: c5caa888da25 Author: lana Date: 2014-08-11 10:05 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/c5caa888da25 Merge Changeset: 9b415daee626 Author: chegar Date: 2014-08-18 10:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/9b415daee626 Merge Changeset: 5282a14f131f Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/5282a14f131f Merge Changeset: 3d1a4bfb6abb Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/3d1a4bfb6abb Added tag jdk9-b28 for changeset 5282a14f131f ! .hgtags Changeset: e58d3ea638c3 Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/e58d3ea638c3 Added tag jdk9-b29 for changeset 3d1a4bfb6abb ! .hgtags Changeset: ddf1ef4a4a54 Author: katleman Date: 2014-09-11 09:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/ddf1ef4a4a54 Added tag jdk9-b30 for changeset e58d3ea638c3 ! .hgtags Changeset: 434628e088ce Author: wetmore Date: 2014-09-11 12:18 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/434628e088ce 8058180: .hgignore should be updated with webrev in all repos Reviewed-by: jrose, katleman, jjg ! .hgignore Changeset: 7af228ae847f Author: lana Date: 2014-09-11 14:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/7af228ae847f Merge Changeset: ffefee7f46fd Author: katleman Date: 2014-09-17 22:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/ffefee7f46fd Added tag jdk9-b31 for changeset 7af228ae847f ! .hgtags Changeset: d35ad0854f68 Author: mkos Date: 2014-09-12 17:20 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/d35ad0854f68 8054548: JAX-WS tools need to updated to work with modular image Summary: Removing java reflection API to get JavaCompiler; using standard javax.tools API instead Reviewed-by: alanb - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ApClassLoader.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/Invoker.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/WsGen.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/WsImport.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/JavacompilerMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/javacompiler.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java Changeset: 838a2f693e51 Author: lana Date: 2014-09-18 13:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/838a2f693e51 Merge - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ApClassLoader.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java Changeset: 2c42a24c7d8c Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/2c42a24c7d8c Added tag jdk9-b32 for changeset 838a2f693e51 ! .hgtags Changeset: ad01ed3c9ac2 Author: mkos Date: 2014-09-25 10:02 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/ad01ed3c9ac2 8038966: JAX-WS handles wrongly xsd:any arguments for Web services Reviewed-by: coffeys ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/ContentHandlerAdaptor.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXStreamConnector.java Changeset: 77a45995dd3b Author: lana Date: 2014-09-25 16:20 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/77a45995dd3b Merge Changeset: 28ea43d925f1 Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/28ea43d925f1 Added tag jdk9-b33 for changeset 77a45995dd3b ! .hgtags Changeset: afe0c89e2edb Author: katleman Date: 2014-10-09 11:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/afe0c89e2edb Added tag jdk9-b34 for changeset 28ea43d925f1 ! .hgtags From maurizio.cimadamore at oracle.com Wed Oct 15 13:02:57 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:02:57 +0000 Subject: hg: valhalla/valhalla/jaxp: 18 new changesets Message-ID: <201410151302.s9FD2vlm028477@aojmv0008> Changeset: dc9a296f77a7 Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/dc9a296f77a7 Added tag jdk9-b26 for changeset a5aea8318ae4 ! .hgtags Changeset: f88b3047d322 Author: lana Date: 2014-08-11 10:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/f88b3047d322 Merge Changeset: 3fa16315f4b5 Author: chegar Date: 2014-08-18 10:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/3fa16315f4b5 Merge Changeset: dc1e26434b3f Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/dc1e26434b3f Merge Changeset: d83a4c26b52e Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/d83a4c26b52e Added tag jdk9-b28 for changeset dc1e26434b3f ! .hgtags Changeset: 65e6291d9ba9 Author: joehw Date: 2014-08-29 11:49 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/65e6291d9ba9 8037819: Xerces Update: jaxp/validation/XMLSchemaFactory Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ValidatedInfo.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties + src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ConfigurableValidationState.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchema.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/StandardParserConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java Changeset: 30adcd13a313 Author: lana Date: 2014-08-29 11:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/30adcd13a313 Merge Changeset: d181d4002214 Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/d181d4002214 Added tag jdk9-b29 for changeset 30adcd13a313 ! .hgtags Changeset: c31f1eee7700 Author: katleman Date: 2014-09-11 09:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/c31f1eee7700 Added tag jdk9-b30 for changeset d181d4002214 ! .hgtags Changeset: 93a5ed174422 Author: joehw Date: 2014-09-05 14:04 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/93a5ed174422 8056202: Xerces Update: Catalog Resolver Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogException.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Resolver.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/Debug.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/FileURL.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/Namespaces.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/PublicId.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/CatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogParser.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/ExtendedXMLCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/OASISXMLCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogParser.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXParserHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/TR9401CatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/TextCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/XCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/tools/CatalogResolver.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingParser.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLFilter.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLReader.java Changeset: 705a3999eb77 Author: martin Date: 2014-09-10 15:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/705a3999eb77 8058175: [XML 1.0/1.1] - Attribute values with supplemental characters are being corrupted. Reviewed-by: joehw ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: e3853f655392 Author: lana Date: 2014-09-10 19:38 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/e3853f655392 Merge Changeset: 9729d853cb16 Author: wetmore Date: 2014-09-11 12:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/9729d853cb16 8058180: .hgignore should be updated with webrev in all repos Reviewed-by: jrose, katleman, jjg ! .hgignore Changeset: 292317ebc7db Author: lana Date: 2014-09-11 14:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/292317ebc7db Merge Changeset: b940ca3d2c7e Author: katleman Date: 2014-09-17 22:55 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/b940ca3d2c7e Added tag jdk9-b31 for changeset 292317ebc7db ! .hgtags Changeset: 46b360454dad Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/46b360454dad Added tag jdk9-b32 for changeset b940ca3d2c7e ! .hgtags Changeset: 6b343b9b7a70 Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/6b343b9b7a70 Added tag jdk9-b33 for changeset 46b360454dad ! .hgtags Changeset: b9370464572f Author: katleman Date: 2014-10-09 11:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/b9370464572f Added tag jdk9-b34 for changeset 6b343b9b7a70 ! .hgtags From maurizio.cimadamore at oracle.com Wed Oct 15 13:23:47 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:23:47 +0000 Subject: hg: valhalla/valhalla/langtools: Uncomment previously failing static test. Message-ID: <201410151323.s9FDNlwq002258@aojmv0008> Changeset: 17f0c148df51 Author: mcimadamore Date: 2014-10-15 14:23 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/17f0c148df51 Uncomment previously failing static test. ! test/tools/javac/valhalla/typespec/Statics01.java From pbenedict at apache.org Wed Oct 15 13:48:23 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 15 Oct 2014 08:48:23 -0500 Subject: Static fields in specialized classes In-Reply-To: References: <543C17C3.50104@oracle.com> <543DB8EE.6070801@oracle.com> Message-ID: I throw my lot in with Ben and Stephen. I don't think specialization should be exposed to the point that you can tell the difference with .class. That's very disruptive to code and surprising. Rather, I think you should expose more methods on Class to query the specialization type -- that was something I recommended in the beginning and still favor. Cheers, Paul On Wed, Oct 15, 2014 at 3:30 AM, Ben Lewis wrote: > I think having Foo.class and Foo.class be different is a mistake. > > class Person{} > > class Employee extends Bar{ > //lots of other stuff irrelevant to T > T getId(){ ? } > } > > Person p1=new Employee(); > Person p2=new Employee(); > > As I understand it > > p1.class==Employee.class;//true > p2.class==Employee.class;//false > p1 instanceof Employee;//true > p2 instanceof Employee;//false > > How to determine b2 comes from ?source class? Employee? > > This will cause bugs in situations where the programmer expects how the > class hierarchy acts now rather than changing it to where specialisation > having a different class. This would also mean migrating to > will cause backward compatibility issues. > > For example > > if(p instanceof Employee){ > //do something > }else{ > //do something else > } > > if written before specialisations It would do as expected but after and if > p=new Employee() it would execute the else block not as expected when > the code is written. > > On Wed, Oct 15, 2014 at 12:59 PM, Brian Goetz > wrote: > > > My gut feeling is that this is undesirable and should be disallowed, > >> and that perhaps we shouldn't even be able to observe Foo.class > >> at all. > >> > > > > If you think about the problem a little more, I think you'll find that > > this is wishful thinking. (But of course, you're free to have a gut > > feeling without having thought about it at all.) > > > > After all, if specialization is intended to be viewed primarily as an > >> implementation detail > >> > > > > It is an implementation detail in the same sense that erasure is; that > > generics are implemented by erasure almost certainly leaks into the > user's > > perception too. (Erasure is why you can't have Foo.class, for > > example. Among many other things that the user has to pay attention to.) > > > > class Foo { > > T get() { ... } > > } > > > > Consider the members of various instantiations of Foo. > > > > The signature of get() in Foo is "String get()", but the > signature > > of get() in Foo is "int get()". The erasure of the first is "Object > > get()"; the erasure of the second is "int get()". While all erased > > reference instantiations can be implemented by the same class, the > > primitive/value instantiations cannot be. > > > > Similarly, Foo can't extend Foo (because that really means Foo > extends Object>, and has to for compatibility reasons), nor can it extend > > raw Foo. (Which is fine; raw types exist solely to support migration > from > > ungenerified codebases to generified ones.) > > > > We could hide the existence of List.class, but that would just make > > life harder for users, who would then have to jump through bigger hoops > to > > reflect over the members of List (which are different from the > members > > of List, even after erasure.) > > > > In other words, while the Java language/library changes may be > >> expressed by some improvements to reflection, I'd be concerned about > >> the many implemented algorithms based on reflection. > >> > > > > It is of course reasonable to be concerned. Stay tuned and see if your > > concerns are addressed. > > > From maurizio.cimadamore at oracle.com Wed Oct 15 13:03:43 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:03:43 +0000 Subject: hg: valhalla/valhalla/nashorn: 94 new changesets Message-ID: <201410151303.s9FD3h9a028764@aojmv0008> Changeset: 53c5f1286192 Author: sundar Date: 2014-08-06 22:11 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/53c5f1286192 8053910: ScriptObjectMirror causing havoc with Invocation interface Reviewed-by: jlaskey, attila, hannesw ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 25a50ee3bb8a Author: attila Date: 2014-08-07 11:06 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/25a50ee3bb8a 8046026: CompiledFunction.relinkComposableInvoker assert is being hit Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java + test/script/basic/JDK-8046026.js + test/script/basic/JDK-8046026.js.EXPECTED Changeset: b850ada7a38d Author: sundar Date: 2014-08-07 19:19 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/b850ada7a38d 8051346: Test262 tests for ECMAScript 5 now in branch "es5-tests" Reviewed-by: attila, hannesw ! make/build.xml + samples/zipfs.js ! samples/ziplist.js Changeset: 19795e6f1ecf Author: hannesw Date: 2014-08-08 12:50 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/19795e6f1ecf 8043956: Make code caching work with optimistic typing and lazy compilation Reviewed-by: attila, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/CodeStore.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java - src/jdk/nashorn/internal/runtime/CompiledFunctions.java - src/jdk/nashorn/internal/runtime/CompiledScript.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java + src/jdk/nashorn/internal/runtime/FunctionInitializer.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk/nashorn/internal/runtime/StoredScript.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/runtime/CodeStoreAndPathTest.java Changeset: e32f2d049838 Author: sundar Date: 2014-08-08 19:07 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e32f2d049838 8054651: Global.initConstructor and ScriptFunction.getPrototype(Object) can have stricter types Reviewed-by: attila, jlaskey, hannesw ! make/project.properties ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/annotations/Optimistic.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java Changeset: fba1c5d47366 Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fba1c5d47366 Added tag jdk9-b26 for changeset e32f2d049838 ! .hgtags Changeset: 5bf075eb3c23 Author: sundar Date: 2014-08-11 20:35 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/5bf075eb3c23 8054503: test/script/external/test262/test/suite/ch12/12.6/12.6.4/12.6.4-2.js fails with tip Reviewed-by: jlaskey, hannesw, attila ! make/project.properties ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8054503.js Changeset: f4562cb6da38 Author: lana Date: 2014-08-11 10:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f4562cb6da38 Merge ! .hgtags - src/jdk/nashorn/internal/runtime/CompiledFunctions.java - src/jdk/nashorn/internal/runtime/CompiledScript.java Changeset: 7ab42c461a8c Author: hannesw Date: 2014-08-12 13:22 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/7ab42c461a8c 8044851: nashorn properties leak memory Reviewed-by: attila, jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + test/script/nosecurity/JDK-8044851.js + test/script/nosecurity/JDK-8044851.js.EXPECTED Changeset: 11a4f68806bc Author: hannesw Date: 2014-08-12 13:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/11a4f68806bc 8054898: Avoid creation of empty type info files Reviewed-by: attila, sundar, jlaskey ! src/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java Changeset: e84cfe70c504 Author: sundar Date: 2014-08-13 15:00 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e84cfe70c504 8054993: type info cache may be disabled for test262 and tests explicitly changing that property should use @fork Reviewed-by: lagergren, hannesw ! make/build.xml ! test/script/basic/compile-octane-normal.js ! test/script/basic/compile-octane-splitter.js Changeset: c0dd84255936 Author: sundar Date: 2014-08-13 21:03 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c0dd84255936 8055034: jjs exits interactive mode if exception was thrown when trying to print value of last evaluated expression Reviewed-by: jlaskey, attila ! src/jdk/nashorn/tools/Shell.java + test/script/nosecurity/JDK-8055034.js + test/script/nosecurity/JDK-8055034.js.EXPECTED Changeset: 72c86f6eb628 Author: attila Date: 2014-08-14 14:35 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/72c86f6eb628 8055042: Compile-time expression evaluator was missing variables Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk/nashorn/internal/codegen/TypeEvaluator.java Changeset: c116b81e69e9 Author: sundar Date: 2014-08-14 18:54 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c116b81e69e9 8055107: Extension directives to turn on callsite profiling, tracing, AST print and other debug features locally Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/trusted/JDK-8055107.js Changeset: 6831ff454574 Author: sundar Date: 2014-08-14 20:14 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/6831ff454574 8055139: test/script/trusted/JDK-8055107.js fails with access control exception Reviewed-by: lagergren, attila, jlaskey = test/script/nosecurity/JDK-8055107.js < test/script/trusted/JDK-8055107.js Changeset: f82b83cf73ae Author: attila Date: 2014-08-15 17:30 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f82b83cf73ae 8055199: Tidy up Nashorn codebase for code standards (August 2014) Reviewed-by: hannesw, lagergren ! docs/genshelldoc.js ! docs/source/importpackageclass.js ! docs/source/javaarray.js ! docs/source/javaextend.js ! docs/source/javaimporter.js ! docs/source/javatypes.js ! docs/source/overload.js ! docs/source/runnable.js ! docs/source/samfunc.js ! docs/source/test.js ! samples/array_mapreduce.js ! samples/astviewer.js ! samples/barchart_weather.js ! samples/call_lambda.js ! samples/counters.js ! samples/dirname.js ! samples/disassemble.js ! samples/engine/accessvar.js ! samples/engine/callfunc.js ! samples/engine/callmethod.js ! samples/engine/exposevar.js ! samples/engine/foreignobject.js ! samples/engine/hello.js ! samples/engine/interface.js ! samples/engine/interface2.js ! samples/engine/lambda_as_func.js ! samples/env.js ! samples/expression_closure.js ! samples/filebrowser.js ! samples/fileline.js ! samples/fizzbuzz.js ! samples/for_each.js ! samples/gaussian_random.js ! samples/gaussian_random_bind.js ! samples/gutenberg.js ! samples/heredoc.js ! samples/interface_impl.js ! samples/javaastviewer.js ! samples/javacastcounter.js ! samples/javafoovars.js ! samples/javaimporter.js ! samples/javalist.js ! samples/javamap.js ! samples/javashell.js ! samples/jsadapter_dom.js ! samples/jsobj_example.js ! samples/jsobject.js ! samples/jsobject_mapreduce.js ! samples/jsonviewer.js ! samples/letter.js ! samples/list_mapreduce.js ! samples/locales.js ! samples/logisticmap.js ! samples/options.js ! samples/parser.js ! samples/readLine.js ! samples/sam_function.js ! samples/shell.js ! samples/stack.js ! samples/uniform_random.js ! samples/uniq.js ! samples/uniqs.js ! samples/weather.js ! samples/word_histogram.js ! samples/zipfs.js ! samples/ziplist.js ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/CodeStore.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/FunctionInitializer.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! test/script/basic/JDK-8038413.js ! test/script/basic/JDK-8043232.js ! test/script/basic/JDK-8044695.js ! test/script/basic/JDK-8044750.js ! test/script/basic/JDK-8046026.js ! test/script/basic/JDK-8046905.js ! test/script/basic/JDK-8047067.js ! test/script/basic/JDK-8047166.js ! test/script/basic/JDK-8047357.js ! test/script/basic/JDK-8047369.js ! test/script/basic/JDK-8047371.js ! test/script/basic/JDK-8047728.js ! test/script/basic/JDK-8047959.js ! test/script/basic/JDK-8048079_1.js ! test/script/basic/JDK-8048079_2.js ! test/script/basic/JDK-8048586.js ! test/script/basic/JDK-8049086.js ! test/script/basic/JDK-8051439.js ! test/script/basic/compile-octane-normal.js ! test/script/basic/compile-octane-splitter.js ! test/script/basic/compile-octane.js ! test/script/nosecurity/JDK-8044798.js ! test/script/nosecurity/JDK-8044851.js ! test/script/nosecurity/JDK-8050964.js ! test/script/nosecurity/JDK-8055034.js ! test/script/nosecurity/debuggersupportapi.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java ! test/src/jdk/nashorn/internal/runtime/ConsStringTest.java Changeset: c93b6091b11e Author: chegar Date: 2014-08-18 10:59 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c93b6091b11e Merge ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/TypeEvaluator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/CallNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Node.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/annotations/Optimistic.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java - src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunctions.java - src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledScript.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FunctionInitializer.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StoredScript.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java Changeset: 5cc4c68ee666 Author: hannesw Date: 2014-08-19 11:25 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/5cc4c68ee666 8055368: Ant build broken after modular source code change Reviewed-by: attila, sundar, lagergren ! make/project.properties Changeset: d564abed1e6a Author: sundar Date: 2014-08-19 18:14 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/d564abed1e6a 8055395: Nashorn should use source, target to be 1.8 and use ASM5 version for generated code Reviewed-by: attila, lagergren, jlaskey ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! make/build.xml ! make/project.properties + samples/find_nonfinals.js + samples/try_with_resource.js Changeset: 57500636de77 Author: sundar Date: 2014-08-20 20:04 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/57500636de77 8050078: Nashorn ClassFilter Support Reviewed-by: lagergren, hannesw + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ClassFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8015969.js + test/script/trusted/classfilter.js + test/script/trusted/classfilter.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: 00c31e5eaf26 Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/00c31e5eaf26 Merge ! .hgtags - src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunctions.java - src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledScript.java Changeset: adc2b63e654a Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/adc2b63e654a Added tag jdk9-b28 for changeset 00c31e5eaf26 ! .hgtags Changeset: 3516182f0612 Author: sundar Date: 2014-08-20 21:32 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/3516182f0612 8055687: Wrong "this" passed to JSObject.eval call Reviewed-by: lagergren, hannesw, attila ! samples/find_nonfinals.js + samples/find_nonfinals2.js ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 127a155b49c8 Author: sundar Date: 2014-08-21 20:06 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/127a155b49c8 8055762: Nashorn misses linker for netscape.javascript.JSObject instances Reviewed-by: lagergren, jlaskey ! make/build.xml ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java + test/script/basic/JDK-8055762.js + test/script/basic/JDK-8055762.js.EXPECTED Changeset: ee00439d1d54 Author: sundar Date: 2014-08-22 15:47 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/ee00439d1d54 8055796: JSObject and browser JSObject linkers should provide fallback to call underlying Java methods directly Reviewed-by: attila, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8055796.js + test/script/basic/JDK-8055796.js.EXPECTED Changeset: 0f91116bb4bd Author: sundar Date: 2014-08-22 22:50 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/0f91116bb4bd 8055830: JDK-8015969.js is silently failing Reviewed-by: lagergren, jlaskey, hannesw ! test/script/basic/JDK-8015969.js Changeset: 11e4f12a45b0 Author: yan Date: 2014-08-25 17:38 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/11e4f12a45b0 8055878: Nashorn: all tests failed with AccessControlException Reviewed-by: sundar, hannesw Contributed-by: Sergey Lugovoy ! make/build.xml Changeset: ad7a46083364 Author: sundar Date: 2014-08-25 20:26 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/ad7a46083364 8055899: Two nashorn tests fail in 8u40 nightly build with ClassNotFoundException Reviewed-by: jlaskey, lagergren ! test/script/basic/JDK-8055762.js ! test/script/basic/JDK-8055796.js ! test/script/basic/JDK-8055796.js.EXPECTED + test/script/basic/JDK-8055796_2.js + test/script/basic/JDK-8055796_2.js.EXPECTED Changeset: 494092ee7a01 Author: attila Date: 2014-08-25 22:36 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/494092ee7a01 8055870: iteration fails if index var is not used Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8055870.js + test/script/basic/JDK-8055870.js.EXPECTED Changeset: d6b5c2c6c1d0 Author: yan Date: 2014-08-26 13:26 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/d6b5c2c6c1d0 8055811: Tests for Nashorn ClassFilter Support Reviewed-by: sundar, attila Contributed-by: Sergey Lugovoy + test/script/trusted/classfilter_extends.js + test/script/trusted/classfilter_extends.js.EXPECTED + test/script/trusted/classfilter_mozilla_compat.js + test/script/trusted/classfilter_mozilla_compat.js.EXPECTED + test/src/jdk/nashorn/internal/runtime/ClassFilterTest.java Changeset: 10c95d040380 Author: attila Date: 2014-08-26 11:31 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/10c95d040380 8055911: Don't use String.intern for IdentNode Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java Changeset: 9388010e3a8e Author: attila Date: 2014-08-26 11:32 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/9388010e3a8e 8055913: Node.hashCode() delegates to Object.hashCode() and is hot Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Node.java Changeset: f03ee361fa76 Author: lagergren Date: 2014-08-26 11:42 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f03ee361fa76 8055906: Avoid throwing an exception with filled in stack trace as part of the normal control flow Reviewed-by: attila, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ApplySpecialization.java Changeset: d81f7c897bdf Author: attila Date: 2014-08-26 11:45 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/d81f7c897bdf 8055923: collect timings using System.nanoTime Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Timing.java Changeset: 3c354c3af1d8 Author: sundar Date: 2014-08-26 17:21 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/3c354c3af1d8 8056050: runExternalJsTest method in test/jdk/nashorn/internal/runtime/ClassFilter.java slows down "ant test" Reviewed-by: attila, jlaskey ! test/src/jdk/nashorn/internal/runtime/ClassFilterTest.java Changeset: fda747208c6f Author: attila Date: 2014-08-26 15:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fda747208c6f 8055954: Do not parallelize class installation Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java Changeset: 46af7f9765dc Author: attila Date: 2014-08-26 15:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/46af7f9765dc 8056052: Source.getContent() does excess Object.clone() Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java ! test/src/jdk/nashorn/internal/runtime/SourceTest.java Changeset: fa79d912da1b Author: attila Date: 2014-08-26 15:52 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fa79d912da1b 8056025: CompilationPhase.setStates() is hot in class installation phase Reviewed-by: jlaskey, sundar + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/AssertsEnabled.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java Changeset: dbb723e6c54c Author: sundar Date: 2014-08-26 22:57 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/dbb723e6c54c 8056094: [nashorn] tests fail when running via jtreg Reviewed-by: jlaskey, hannesw ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: e56bfeff25a9 Author: sundar Date: 2014-08-27 14:27 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e56bfeff25a9 8056123: Anonymous function statements leak internal function names into global scope Reviewed-by: hannesw, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java + test/script/basic/JDK-8056123.js ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 734bdd565748 Author: attila Date: 2014-08-28 16:38 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/734bdd565748 8056243: OptimisticTypePersistence should refuse to work in symlinked directories Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java Changeset: e541ebaf2ab7 Author: lana Date: 2014-08-29 11:58 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e541ebaf2ab7 Merge Changeset: 0cf05971521d Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/0cf05971521d Added tag jdk9-b29 for changeset e541ebaf2ab7 ! .hgtags Changeset: 2520d5e7bc5f Author: yan Date: 2014-09-01 17:34 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/2520d5e7bc5f 8054343: Nashorn: Some tests fails on windows with AccessControlException Reviewed-by: lagergren, sundar Contributed-by: Sergey Lugovoy ! test/script/basic/compile-octane-normal.js ! test/script/basic/compile-octane-splitter.js ! test/script/basic/compile-octane.js Changeset: 20d8ab569eb6 Author: attila Date: 2014-09-03 14:33 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/20d8ab569eb6 8056913: Limit the size of type info cache on disk Reviewed-by: jlaskey, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java Changeset: 0b7b3bd3cc04 Author: lagergren Date: 2014-09-04 10:52 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/0b7b3bd3cc04 8057019: Various problems with extra arguments to applies Reviewed-by: attila, hannesw, jlaskey - bin/dump_octane_code.sh - bin/fixorphantests.sh - bin/fixwhitespace.sh - bin/jjsdebug.sh - bin/rm-non-tracked.sh - bin/run_octane.sh - bin/rundiff.sh - bin/runopt.sh - bin/runopt_noassert.sh - bin/runopt_nojfr.sh ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8057019-2.js + test/script/basic/JDK-8057019-2.js.EXPECTED + test/script/basic/JDK-8057019-payload.js + test/script/basic/JDK-8057019.js + test/script/basic/JDK-8057019.js.EXPECTED ! test/script/basic/apply_to_call/apply_to_call4.js.EXPECTED Changeset: ef3c1957d29b Author: lagergren Date: 2014-09-04 14:42 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/ef3c1957d29b 8057551: Let the -d flag dump _all_ generated classes to disk and work outside --compile-only mode Reviewed-by: attila, jlaskey ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/DumpBytecode.java Changeset: 2f0161551858 Author: hannesw Date: 2014-09-04 15:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/2f0161551858 8051889: Implement block scoping in symbol assignment and scope computation Reviewed-by: attila, lagergren ! make/build.xml ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/TypeEvaluator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Symbol.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/VarNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java + test/script/basic/es6/block-function-decl.js + test/script/basic/es6/block-function-decl.js.EXPECTED + test/script/basic/es6/const-empty.js + test/script/basic/es6/const-empty.js.EXPECTED + test/script/basic/es6/const-reassign.js + test/script/basic/es6/const-reassign.js.EXPECTED + test/script/basic/es6/const-redeclare.js + test/script/basic/es6/const-redeclare.js.EXPECTED + test/script/basic/es6/const-self.js + test/script/basic/es6/const-self.js.EXPECTED + test/script/basic/es6/const-tdz.js + test/script/basic/es6/const-tdz.js.EXPECTED + test/script/basic/es6/const.js + test/script/basic/es6/const.js.EXPECTED + test/script/basic/es6/for-let.js + test/script/basic/es6/for-let.js.EXPECTED + test/script/basic/es6/let-eval.js + test/script/basic/es6/let-eval.js.EXPECTED + test/script/basic/es6/let-load-lib.js + test/script/basic/es6/let-load.js + test/script/basic/es6/let-load.js.EXPECTED + test/script/basic/es6/let-nodeclare.js + test/script/basic/es6/let-nodeclare.js.EXPECTED + test/script/basic/es6/let-redeclare.js + test/script/basic/es6/let-redeclare.js.EXPECTED + test/script/basic/es6/let-self.js + test/script/basic/es6/let-self.js.EXPECTED + test/script/basic/es6/let-tdz.js + test/script/basic/es6/let-tdz.js.EXPECTED + test/script/basic/es6/let.js + test/script/basic/es6/let.js.EXPECTED ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 37152862918f Author: attila Date: 2014-09-04 18:57 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/37152862918f 8056129: AtomicInteger is treated as primitive number with optimistic compilation Reviewed-by: jlaskey, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayData.java + test/script/basic/JDK-8056129.js + test/script/basic/JDK-8056129.js.EXPECTED Changeset: 072dbed6c5d9 Author: lana Date: 2014-09-04 14:45 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/072dbed6c5d9 Merge Changeset: 45a09ce8502e Author: katleman Date: 2014-09-11 09:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/45a09ce8502e Added tag jdk9-b30 for changeset 072dbed6c5d9 ! .hgtags Changeset: f04f14587586 Author: lagergren Date: 2014-09-05 16:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f04f14587586 8057611: Nashorn did not dump the JOx classes to disk when running with the -d flag Reviewed-by: attila, sundar, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 4258ccc2eb8a Author: lagergren Date: 2014-09-05 16:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/4258ccc2eb8a 8057588: Lots of trivial (empty) classes were generated by the Nashorn compiler as part of restOf-method generation Reviewed-by: attila, sundar, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/CompileUnitHolder.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 459874975ef6 Author: sundar Date: 2014-09-08 15:51 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/459874975ef6 8057742: ant clean test should not fail if one or more external test suites are missing Reviewed-by: lagergren, hannesw - test/script/basic/JDK-8048079_1.js - test/script/basic/JDK-8048079_1.js.EXPECTED + test/script/basic/JDK-8048079_1a.js + test/script/basic/JDK-8048079_1a.js.EXPECTED + test/script/basic/JDK-8048079_1b.js + test/script/basic/JDK-8048079_1b.js.EXPECTED - test/script/basic/JDK-8048079_2.js - test/script/basic/JDK-8048079_2.js.EXPECTED + test/script/basic/JDK-8048079_2a.js + test/script/basic/JDK-8048079_2a.js.EXPECTED + test/script/basic/JDK-8048079_2b.js + test/script/basic/JDK-8048079_2b.js.EXPECTED ! test/script/basic/splitter.js ! test/script/basic/splitter.js.EXPECTED + test/script/basic/splitter_prototype.js + test/script/basic/splitter_prototype.js.EXPECTED + test/script/basic/splitter_yui.js + test/script/basic/splitter_yui.js.EXPECTED ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java Changeset: 884a8ffb6038 Author: yan Date: 2014-09-08 15:37 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/884a8ffb6038 8057678: Tests for let and const keywords in Nashorn Reviewed-by: hannesw, lagergren Contributed-by: Sergey Lugovoy + test/script/basic/es6/const-redeclare-extra.js + test/script/basic/es6/const-redeclare-extra.js.EXPECTED + test/script/basic/es6/let-redeclare-extra.js + test/script/basic/es6/let-redeclare-extra.js.EXPECTED + test/script/basic/es6/let_const_closure.js + test/script/basic/es6/let_const_closure.js.EXPECTED + test/script/basic/es6/let_const_reuse.js + test/script/basic/es6/let_const_reuse.js.EXPECTED + test/script/basic/es6/let_different_types.js + test/script/basic/es6/let_different_types.js.EXPECTED + test/script/basic/es6/let_loops.js + test/script/basic/es6/let_loops.js.EXPECTED Changeset: fc80190e129f Author: attila Date: 2014-09-08 18:40 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fc80190e129f 8057148: Skip nested functions on reparse Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/TokenStream.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Timing.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java ! test/script/basic/optimistic_check_type.js Changeset: c17045fd979c Author: attila Date: 2014-09-09 15:33 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c17045fd979c 8057930: remove eval ID Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! test/script/basic/JDK-8030182_2.js ! test/script/basic/JDK-8030182_2.js.EXPECTED ! test/script/basic/es6/const-empty.js.EXPECTED ! test/script/basic/es6/const-redeclare-extra.js.EXPECTED ! test/script/basic/es6/const-redeclare.js.EXPECTED ! test/script/basic/es6/let-redeclare-extra.js.EXPECTED ! test/script/basic/es6/let-redeclare.js.EXPECTED ! test/script/basic/es6/let_const_reuse.js.EXPECTED Changeset: dcc08ab6777a Author: attila Date: 2014-09-09 15:34 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/dcc08ab6777a 8057931: Instead of not skipping small functions in parser, make lexer avoid them instead Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Lexer.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java Changeset: 578f8ca1336a Author: lagergren Date: 2014-09-10 12:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/578f8ca1336a 8057703: More empty classes generated by Nashorn Reviewed-by: attila, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGeneratorLexicalContext.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Timing.java Changeset: 2c5ba6bd48a7 Author: attila Date: 2014-09-10 13:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/2c5ba6bd48a7 8034954: Optimistic iteration in for-in and for-each Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/TypeEvaluator.java Changeset: 8a4af0397070 Author: hannesw Date: 2014-09-10 15:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/8a4af0397070 8057021: UserAccessorProperty guards fail with multiple globals Reviewed-by: attila, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! test/src/jdk/nashorn/api/scripting/ScopeTest.java Changeset: ba55f0a6473f Author: lana Date: 2014-09-10 19:37 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/ba55f0a6473f Merge - test/script/basic/JDK-8048079_1.js - test/script/basic/JDK-8048079_1.js.EXPECTED - test/script/basic/JDK-8048079_2.js - test/script/basic/JDK-8048079_2.js.EXPECTED Changeset: 1f2fa7bd6d95 Author: attila Date: 2014-09-11 17:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/1f2fa7bd6d95 8058100: Reduce the RecompilableScriptFunctionData footprint Reviewed-by: jlaskey, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AllocationStrategy.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java Changeset: 5a238407c8f1 Author: hannesw Date: 2014-09-11 17:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/5a238407c8f1 8058179: Global constants get in the way of self-modifying properties Reviewed-by: attila, jlaskey, sundar, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8058179.js + test/script/basic/JDK-8058179.js.EXPECTED Changeset: 8ad3a44f2927 Author: wetmore Date: 2014-09-11 12:18 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/8ad3a44f2927 8058180: .hgignore should be updated with webrev in all repos Reviewed-by: jrose, katleman, jjg ! .hgignore Changeset: 77efdecfa2a5 Author: lana Date: 2014-09-11 14:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/77efdecfa2a5 Merge - test/script/basic/JDK-8048079_1.js - test/script/basic/JDK-8048079_1.js.EXPECTED - test/script/basic/JDK-8048079_2.js - test/script/basic/JDK-8048079_2.js.EXPECTED Changeset: 399aa8fc2905 Author: katleman Date: 2014-09-17 22:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/399aa8fc2905 Added tag jdk9-b31 for changeset 77efdecfa2a5 ! .hgtags Changeset: a20309596c42 Author: hannesw Date: 2014-09-12 11:00 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a20309596c42 8057743: Single quotes must be escaped in message resource file Reviewed-by: attila, lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8043232.js.EXPECTED ! test/script/basic/JDK-8049242.js.EXPECTED Changeset: ec55eed621a8 Author: hannesw Date: 2014-09-12 15:01 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/ec55eed621a8 8058304: Non-serializable fields in serializable classes Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java Changeset: e86dd06a8ccb Author: sundar Date: 2014-09-15 15:18 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e86dd06a8ccb 8058422: Users should be able to overwrite "context" and "engine" variables Reviewed-by: lagergren, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8058422.js ! test/src/jdk/nashorn/api/scripting/ScopeTest.java Changeset: 10f36ba5ef80 Author: hannesw Date: 2014-09-15 17:51 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/10f36ba5ef80 8056978: ClassCastException: cannot cast jdk.nashorn.internal.scripts.JO* Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyMap.java + test/script/basic/JDK-8056978.js + test/script/basic/JDK-8056978.js.EXPECTED Changeset: 3936203c7dc8 Author: sundar Date: 2014-09-16 17:04 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/3936203c7dc8 8058545: With strict mode, bean property assignment of a non-existent property should result in TypeError Reviewed-by: hannesw, lagergren ! README ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/JDK-8058545.js Changeset: 9f8ab1b79632 Author: sundar Date: 2014-09-16 17:47 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/9f8ab1b79632 8058551: Top level README accidentally modified with changeset 1025:3936203c7dc8 Reviewed-by: jlaskey, hannesw ! README Changeset: fbded97d28ca Author: sundar Date: 2014-09-17 15:02 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fbded97d28ca 8058615: Overload resolution ambiguity involving ConsString Reviewed-by: lagergren, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java + test/script/basic/JDK-8058615.js + test/script/basic/JDK-8058615.js.EXPECTED Changeset: f2771da9af07 Author: yan Date: 2014-09-17 16:44 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f2771da9af07 8057035: Some tests failed using java.awt.Color on Solaris without X11 libraries Reviewed-by: lagergren Contributed-by: Sergey Lugovoy ! test/script/basic/JDK-8043232.js ! test/script/basic/JDK-8043232.js.EXPECTED ! test/script/basic/JDK-8049086.js ! test/script/basic/JDK-8049086.js.EXPECTED ! test/script/basic/JDK-8049242.js ! test/script/basic/JDK-8049242.js.EXPECTED Changeset: 62ba20541b94 Author: lana Date: 2014-09-18 13:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/62ba20541b94 Merge Changeset: fb5890a6e83a Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fb5890a6e83a Added tag jdk9-b32 for changeset 62ba20541b94 ! .hgtags Changeset: 52752e15fe18 Author: hannesw Date: 2014-09-19 13:13 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/52752e15fe18 8046202: Make persistent code store more flexible Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FunctionInitializer.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StoredScript.java Changeset: c1f651636d9c Author: hannesw Date: 2014-09-22 13:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c1f651636d9c 8047764: Indexed or polymorphic set on global affects Object.prototype Reviewed-by: lagergren, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RewriteException.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + test/script/basic/JDK-8047764-strict.js + test/script/basic/JDK-8047764-strict.js.EXPECTED + test/script/basic/JDK-8047764.js + test/script/basic/JDK-8047764.js.EXPECTED Changeset: c3339a31daad Author: attila Date: 2014-09-22 14:46 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c3339a31daad 8058561: NPE in LocalVariableTypesCalculator Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java + test/script/basic/JDK-8058561.js Changeset: 76f31d739efb Author: yan Date: 2014-09-23 15:58 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/76f31d739efb 8057779: Tests failed on Windows when in output contains path to script Reviewed-by: sundar, lagergren, hannesw Contributed-by: Sergey Lugovoy ! test/script/basic/es6/const-empty.js ! test/script/basic/es6/const-redeclare-extra.js ! test/script/basic/es6/const-redeclare.js ! test/script/basic/es6/let-redeclare-extra.js ! test/script/basic/es6/let-redeclare.js ! test/script/basic/es6/let_const_reuse.js Changeset: f0b5e3900a10 Author: lagergren Date: 2014-09-25 15:53 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f0b5e3900a10 8025435: Optimistic builtins support, implemented initial optimistic versions of push, pop, and charCodeAt Reviewed-by: attila, hannesw, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! samples/BufferArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Symbol.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeDataView.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ScriptFunctionImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/OptimisticBuiltins.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Specialization.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StoredScript.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/IntArrayData.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/IntElements.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/IntOrLongElements.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumericElements.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/TypedArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/examples/charcodeat-benchmark.js + test/examples/push-pop-benchmark.js + test/script/basic/apply_to_call/apply_to_call5.js + test/script/basic/apply_to_call/apply_to_call5.js.EXPECTED + test/script/basic/fastpushpop.js + test/script/basic/fastpushpop.js.EXPECTED ! test/script/basic/run-octane.js Changeset: cb930cbfde63 Author: lagergren Date: 2014-09-25 18:21 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/cb930cbfde63 8059132: Nasgen build in JDK9 can't handle new class dependencies to Nashorn - bootstrapping problem Reviewed-by: sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java Changeset: b374d8910e7f Author: lana Date: 2014-09-25 16:21 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/b374d8910e7f Merge - src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java Changeset: 54b29dbf9581 Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/54b29dbf9581 Added tag jdk9-b33 for changeset b374d8910e7f ! .hgtags Changeset: cc3000241e57 Author: lagergren Date: 2014-09-26 18:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/cc3000241e57 8059211: Changed ArrayData.length accessor to use the protected field and fixed javadoc warnings related to this Reviewed-by: attila, hannesw ! samples/BufferArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Debug.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/TypedArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java Changeset: dee18a93b53f Author: lagergren Date: 2014-09-29 14:39 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/dee18a93b53f 8059321: Decrease warmup time by caching common structures that were reused during parse Reviewed-by: attila, shade ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Label.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java Changeset: 17a2d2b61646 Author: attila Date: 2014-10-01 10:26 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/17a2d2b61646 8059370: Unnecessary work in deoptimizing recompilation Reviewed-by: jlaskey, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 3c5cd88e1397 Author: attila Date: 2014-10-01 10:26 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/3c5cd88e1397 8059371: Code duplication in handling of break and continue Reviewed-by: jlaskey, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/JumpStatement.java Changeset: 26c0435ffe0b Author: attila Date: 2014-10-01 12:22 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/26c0435ffe0b 8059372: Code duplication in split emitter Reviewed-by: jlaskey, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/SplitMethodEmitter.java Changeset: 11925a82ad9f Author: attila Date: 2014-10-02 16:30 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/11925a82ad9f 8059346: Single class loader is used to load compiled bytecode Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java Changeset: 6008e2ea42c2 Author: erikj Date: 2014-10-03 10:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/6008e2ea42c2 8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? Reviewed-by: tbell, attila, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! make/BuildNashorn.gmk Changeset: 4ece2dad8c37 Author: lana Date: 2014-10-03 12:10 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/4ece2dad8c37 Merge Changeset: a930b37f2671 Author: katleman Date: 2014-10-09 11:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a930b37f2671 Added tag jdk9-b34 for changeset 4ece2dad8c37 ! .hgtags From maurizio.cimadamore at oracle.com Wed Oct 15 13:04:55 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:04:55 +0000 Subject: hg: valhalla/valhalla/hotspot: 349 new changesets Message-ID: <201410151304.s9FD4wEW029265@aojmv0008> Changeset: 0bf05fc3b45a Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0bf05fc3b45a Added tag jdk9-b26 for changeset 48b95a073d75 ! .hgtags Changeset: 473cc24bc22a Author: lana Date: 2014-08-11 10:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/473cc24bc22a Merge Changeset: 07a6e56a6936 Author: tschatzl Date: 2014-07-23 09:03 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/07a6e56a6936 8027959: Early reclamation of large objects in G1 Summary: Try to reclaim humongous objects at every young collection after doing a conservative estimate of its liveness. Reviewed-by: brutisso, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp + test/gc/g1/TestEagerReclaimHumongousRegions.java ! test/gc/g1/TestGCLogMessages.java Changeset: bd555dd6ca97 Author: jmasa Date: 2014-07-24 15:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bd555dd6ca97 Merge Changeset: 370ff4c8bd7b Author: dsamersoff Date: 2014-07-28 07:31 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/370ff4c8bd7b 8049046: Deprecated Function in hotspot/src/os/solaris/vm/attachListener_solaris.cpp Summary: replace door_cred with door_ucred call Reviewed-by: dholmes, sspitsyn ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: e5cdc6b42875 Author: sspitsyn Date: 2014-07-30 15:14 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e5cdc6b42875 Merge Changeset: 8842d38f4016 Author: mdoerr Date: 2014-07-29 10:26 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8842d38f4016 8050973: CMS/G1 GC: add missing Resource and Handle mark Summary: Add Resource/HandleMark in the work() method of some AbstractGangTask to reclaim these resources earlier. Reviewed-by: tschatzl, goetz ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: e55980631e8c Author: jmasa Date: 2014-07-31 16:39 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e55980631e8c Merge Changeset: d7ca170d0b32 Author: coleenp Date: 2014-07-31 00:50 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d7ca170d0b32 8051398: jvmti tests fieldacc002, fieldmod002 fail in nightly with errors: (watch#0) wrong location Summary: Didn't handle NULL bcp for native methods Reviewed-by: dcubed, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/frame.cpp Changeset: 53718d9a08c3 Author: ctornqvi Date: 2014-07-31 11:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/53718d9a08c3 8053956: [TESTBUG] Remove @ignore tag from fixed runtime issues Summary: Removed ignore tags from already fixed tests Reviewed-by: gtriantafill, dcubed ! test/runtime/7107135/Test7107135.sh ! test/runtime/SharedArchiveFile/LimitSharedSizes.java ! test/runtime/jsig/Test8017498.sh Changeset: 49dacf251c96 Author: sspitsyn Date: 2014-08-01 16:33 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/49dacf251c96 7187999: dtrace jstack action is broken Summary: Separate jhelper.d and hotspot provider (other USDT probes) Reviewed-by: dholmes, dsamersoff Contributed-by: serguei.spitsyn at oracle.com ! make/solaris/makefiles/dtrace.make Changeset: 6c810eebb532 Author: sspitsyn Date: 2014-08-01 19:03 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6c810eebb532 Merge Changeset: 4986ca806899 Author: hseigel Date: 2014-08-02 16:28 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4986ca806899 8051012: Regression in verifier for method call from inside of a branch Summary: Fix stackmap matching for branches. Reviewed-by: coleenp, lfoltan, acorn ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp Changeset: 6b01f1a4a7bc Author: hseigel Date: 2014-08-05 09:11 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6b01f1a4a7bc 8046233: VerifyError on backward branch Summary: Remove check that causes the VerifyError Reviewed-by: dholmes, coleenp, acorn ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! test/runtime/7116786/Test7116786.java Changeset: 04f50665db45 Author: dsamersoff Date: 2014-08-05 06:11 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/04f50665db45 8025667: Warning from b62 for hotspot.agent.src.os.solaris.proc: use after free Summary: move free call few lines down Reviewed-by: dholmes, sspitsyn ! agent/src/os/solaris/proc/saproc.cpp Changeset: defc10695c19 Author: dsamersoff Date: 2014-08-05 14:18 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/defc10695c19 Merge Changeset: 88aa8ae1a9c8 Author: tschatzl Date: 2014-07-31 09:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/88aa8ae1a9c8 8051973: Eager reclaim leaves marks of marked but reclaimed objects on the next bitmap Summary: Eager reclaim also needs to clear marks of eagerly reclaimed regions if they have already been marked during concurrent mark. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp + test/gc/g1/TestEagerReclaimHumongousRegions2.java Changeset: 26156d95956c Author: jmasa Date: 2014-08-07 20:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/26156d95956c Merge Changeset: de9fde36d673 Author: jmasa Date: 2014-08-01 15:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/de9fde36d673 8031323: Optionally align objects copied to survivor spaces Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp + src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.inline.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8429693b8c5c Author: jmasa Date: 2014-08-03 03:48 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8429693b8c5c Merge Changeset: 14e40cb29ca9 Author: stefank Date: 2014-08-04 15:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/14e40cb29ca9 8051883: TEST.groups references missing test: gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen + test/gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java Changeset: 9d38e660fc7a Author: stefank Date: 2014-08-06 09:55 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9d38e660fc7a 8048269: Add flag to turn off class unloading after G1 concurrent mark Summary: Added -XX:+/-ClassUnloadingWithConcurrentMark Reviewed-by: jmasa, brutisso, mgerdin ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp ! test/TEST.groups + test/gc/class_unloading/AllocateBeyondMetaspaceSize.java - test/gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java + test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java + test/gc/class_unloading/TestG1ClassUnloadingHWM.java Changeset: c9142face067 Author: brutisso Date: 2014-08-07 09:35 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c9142face067 8051837: Remove temporary G1UseParallelRSetUpdating and G1UseParallelRSetScanning flags Reviewed-by: stefank, tschatzl Contributed-by: marcus.larsson at oracle.com ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: a3f928754029 Author: jmasa Date: 2014-08-08 07:38 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a3f928754029 Merge Changeset: c349d53cbc8b Author: anoll Date: 2014-07-24 09:15 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c349d53cbc8b 8050860: Cleanup TypeTuple and TypeFunc Summary: Declared fields TypeFunc::_domain, TypeFunc::_range, TypeTuple::_cnt and TypeTuple::_fields private, changed direct accesses to fields to use accessor methods. Reviewed-by: kvn, vlivanov Contributed-by: Zoltan Majo ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: cb7a6f9f5565 Author: anoll Date: 2014-07-25 09:44 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cb7a6f9f5565 Merge Changeset: c1d7ba5b5d45 Author: thartmann Date: 2014-07-25 10:06 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c1d7ba5b5d45 8040213: C2 does not put all modified nodes on IGVN worklist Summary: Verification code is added that checks if modified nodes are put on the IGVN worklist and modified nodes are processed by 'PhaseIterGVN::transform_old()' Reviewed-by: kvn, jrose ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/rootnode.cpp Changeset: f385f44a27ac Author: anoll Date: 2014-07-25 10:04 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f385f44a27ac Merge ! src/share/vm/opto/compile.cpp Changeset: e2572eca0651 Author: anoll Date: 2014-07-25 10:57 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e2572eca0651 Merge Changeset: 5224135904f8 Author: kvn Date: 2014-07-17 15:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5224135904f8 8050942: PPC64: implement template interpreter for ppc64le Reviewed-by: kvn, goetz Contributed-by: asmundak at google.com ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp Changeset: 4f55d92a7b97 Author: fzhinkin Date: 2014-07-28 15:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4f55d92a7b97 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on Summary: call rtm_deopt() only if there were no compilation bailouts before. Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp + test/compiler/osr/TestOSRWithNonEmptyStack.java Changeset: 26057ecc544b Author: thartmann Date: 2014-07-29 13:54 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/26057ecc544b 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp, runtime/sharedRuntimeTrans.cpp, utilities/globalDefinitions_visCPP.hpp Summary: Fixed parfait warnings in globalDefinitions files by using a union for casts. Reviewed-by: kvn ! src/share/vm/opto/output.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/globalDefinitions_xlc.hpp Changeset: 027c333a08ed Author: thartmann Date: 2014-07-29 13:56 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/027c333a08ed 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp Summary: Fixed parfait warnings caused by __HI and __LO macros in sharedRuntimeMath.hpp by using a union. Reviewed-by: kvn, drchase ! src/share/vm/runtime/sharedRuntimeMath.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp Changeset: 860d53992be0 Author: kvn Date: 2014-07-29 13:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/860d53992be0 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization Summary: Add missing check for reexecute flag to VerifyStack code. Reviewed-by: roland ! src/share/vm/runtime/deoptimization.cpp Changeset: fb3cc0a3799f Author: kvn Date: 2014-07-29 21:28 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fb3cc0a3799f Merge Changeset: 2c26420129d9 Author: roland Date: 2014-07-31 19:59 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2c26420129d9 8054054: 8040121 is broken Summary: C++ code pattern from 8040121 is incorrect Reviewed-by: kvn ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/sharedRuntimeMath.hpp Changeset: 3d02fef8050a Author: roland Date: 2014-08-01 15:57 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3d02fef8050a Merge Changeset: fcb6c71678c9 Author: iignatyev Date: 2014-08-03 12:04 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fcb6c71678c9 8051896: jtreg tests don't use $TESTJAVAOPTS Reviewed-by: kvn, ctornqvi ! test/compiler/5091921/Test7005594.sh ! test/compiler/6857159/Test6857159.sh ! test/compiler/6894807/IsInstanceTest.java ! test/compiler/6894807/Test6894807.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/common.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6888954/vmerrors.sh ! test/runtime/7162488/Test7162488.sh ! test/test_env.sh Changeset: 5eac354f91ad Author: iignatyev Date: 2014-08-03 12:04 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5eac354f91ad 8051484: Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported Reviewed-by: kvn, roland ! test/compiler/6932496/Test6932496.java Changeset: 1ec9cc4fe863 Author: thartmann Date: 2014-08-05 08:25 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1ec9cc4fe863 8054081: Crashes with assert "modified node is not on IGVN._worklist" Summary: Modified safepoint nodes are not added to the IGVN worklist by 'PhaseMacroExpand::scalar_replacement()' Reviewed-by: kvn, roland ! src/share/vm/opto/macro.cpp Changeset: 1c20691306e9 Author: thartmann Date: 2014-07-31 08:39 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1c20691306e9 8053915: bigapps assert failure in C2: modified node is not on IGVN._worklist Summary: Add modified node to the IGVN worklist in 'PhaseIdealLoop::do_range_check'. Reviewed-by: kvn, roland ! src/share/vm/opto/loopTransform.cpp Changeset: 830b015da2c0 Author: anoll Date: 2014-08-05 09:07 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/830b015da2c0 8054013: run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx Summary: Modify hotspot/make/jprt.properties and make/jprt.properties on the top level to add/remove the relevant platforms. Reviewed-by: kvn, roland Contributed-by: Zoltan Majo ! make/jprt.properties Changeset: 026da495e889 Author: anoll Date: 2014-08-05 07:37 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/026da495e889 Merge Changeset: ae45df3285c9 Author: thartmann Date: 2014-08-05 09:58 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ae45df3285c9 8054033: Remove unused references to Compile* Summary: Removed unused references to Compile* missed by JDK-8034812. Reviewed-by: kvn, roland ! src/cpu/ppc/vm/ppc.ad ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/divnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/movenode.cpp ! src/share/vm/opto/movenode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp Changeset: 472cdcd429be Author: morris Date: 2014-08-05 08:19 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/472cdcd429be 8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp Summary: Fixed parfait initialization issue. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 76913ad3cd41 Author: kvn Date: 2014-08-05 15:02 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/76913ad3cd41 8052081: Optimize generated by C2 code for Intel's Atom processor Summary: Allow to execute vectorization and crc32 optimization on Atom. Enable UseFPUForSpilling by default on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/superword.cpp Changeset: e6a16cb925ca Author: thartmann Date: 2014-08-06 08:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e6a16cb925ca 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation Summary: Added missing metadata relocation to 'loadConP_no_oop_cheap' on Sparc if the pointer is referring to a Klass. Added jtreg test. Reviewed-by: kvn, roland ! src/cpu/sparc/vm/sparc.ad + test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java + test/compiler/classUnloading/methodUnloading/WorkerClass.java Changeset: 4ca584c9871d Author: iignatyev Date: 2014-08-06 21:21 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4ca584c9871d 8054410: compiler/7068051/Test7068051.java fails with FileNotFoundException: f3oo.jar Reviewed-by: kvn ! test/compiler/7068051/Test7068051.sh Changeset: c82d0e6f53cd Author: roland Date: 2014-08-02 07:06 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c82d0e6f53cd 8046698: assert(false) failed: only Initialize or AddP expected macro.cpp:943 Summary: PhiNode inserted between AllocateNode and Initialization node confuses allocation elimination Reviewed-by: kvn ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/macro.cpp + test/compiler/macronodes/TestEliminateAllocationPhi.java Changeset: 3e24ce3b2486 Author: morris Date: 2014-08-07 18:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3e24ce3b2486 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp Summary: Fixed parfait initialization issue. Reviewed-by: kvn, twisti ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp Changeset: 85df7d31f622 Author: kvn Date: 2014-08-08 10:35 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/85df7d31f622 Merge Changeset: 6618133bfaf7 Author: amurillo Date: 2014-08-08 11:36 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6618133bfaf7 Merge Changeset: a154419021ba Author: amurillo Date: 2014-08-12 14:04 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a154419021ba Merge Changeset: 2195d56fbfe4 Author: chegar Date: 2014-08-18 10:07 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2195d56fbfe4 Merge Changeset: d797b4e50707 Author: tschatzl Date: 2014-08-07 22:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d797b4e50707 8052170: G1 asserts at collection exit with -XX:-G1DeferredRSUpdate Summary: Do not try to verify timing measures for the redirty logged cards phase when it is not executed. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! test/gc/g1/TestDeferredRSUpdate.java Changeset: de0aa2058110 Author: tschatzl Date: 2014-08-07 22:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/de0aa2058110 8054341: Remove some obsolete code in G1CollectedHeap class Summary: Remove dead code. Reviewed-by: stefank, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 6b5529bd2bb3 Author: jmasa Date: 2014-08-05 15:41 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6b5529bd2bb3 8034056: assert(_heap_alignment >= _space_alignment) failed: heap_alignment less than space_alignment Reviewed-by: tschatzl, sjohanss ! src/share/vm/memory/collectorPolicy.cpp Changeset: a9e233f74c2b Author: jmasa Date: 2014-08-08 16:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a9e233f74c2b Merge Changeset: 075a265e9036 Author: dsamersoff Date: 2014-08-11 04:37 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/075a265e9036 8049049: Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp Summary: Cast arguments on printing Reviewed-by: dholmes, sspitsyn, jbachorik ! agent/src/os/solaris/proc/saproc.cpp Changeset: 91eeb8807a03 Author: zgu Date: 2014-08-07 12:18 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/91eeb8807a03 8046598: Scalable Native memory tracking development Summary: Enhance scalability of native memory tracking Reviewed-by: coleenp, ctornqvi, gtriantafill ! make/excludeSrc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp + src/share/vm/services/allocationSite.hpp + src/share/vm/services/mallocSiteTable.cpp + src/share/vm/services/mallocSiteTable.hpp + src/share/vm/services/mallocTracker.cpp + src/share/vm/services/mallocTracker.hpp + src/share/vm/services/mallocTracker.inline.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp + src/share/vm/services/nmtCommon.cpp + src/share/vm/services/nmtCommon.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp + src/share/vm/services/virtualMemoryTracker.cpp + src/share/vm/services/virtualMemoryTracker.hpp + src/share/vm/utilities/linkedlist.cpp + src/share/vm/utilities/linkedlist.hpp + src/share/vm/utilities/nativeCallStack.cpp + src/share/vm/utilities/nativeCallStack.hpp ! src/share/vm/utilities/vmError.cpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 73d3be1f503d Author: zgu Date: 2014-08-11 07:20 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/73d3be1f503d Merge ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: 0c7f758c15eb Author: zgu Date: 2014-08-11 07:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0c7f758c15eb 8044140: Create NMT (Native Memory Tracking) tests for NMT2 Summary: Create new/modify existing tests for NMT2, which is an internal redesign to address scalability issues in the first implementation. Reviewed-by: ctornqvi, zgu Contributed-by: George Triantafillou ! test/TEST.ROOT ! test/TEST.groups ! test/runtime/NMT/BaselineWithParameter.java ! test/runtime/NMT/CommandLineDetail.java ! test/runtime/NMT/CommandLineEmptyArgument.java ! test/runtime/NMT/CommandLineInvalidArgument.java ! test/runtime/NMT/CommandLineSummary.java ! test/runtime/NMT/CommandLineTurnOffNMT.java ! test/runtime/NMT/JcmdScale.java ! test/runtime/NMT/JcmdWithNMTDisabled.java ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java ! test/runtime/NMT/ReleaseCommittedMemory.java ! test/runtime/NMT/ShutdownTwice.java ! test/runtime/NMT/SummaryAfterShutdown.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 5217fa82f1a4 Author: zgu Date: 2014-08-11 10:18 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5217fa82f1a4 6424123: JVM crashes on failed 'strdup' call Summary: Calling os::malloc()/os::strdup() and new os::strdup_check_oom() instead of ::malloc()/::strdup() for native memory tracking purpose Reviewed-by: coleenp, ctornqvi, kvn ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/os/aix/vm/os_aix.cpp ! src/os/aix/vm/porting_aix.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/management.cpp ! src/share/vm/shark/sharkBuilder.cpp Changeset: 4750cc1f4306 Author: coleenp Date: 2014-08-12 10:48 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4750cc1f4306 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero Summary: These options have been long disabled in Xmixed mode because they prevent these small methods from being inlined and are subject to bit rot, and we don't need more macro assembler code to maintain and change if the constant pool cache format changes. Reviewed-by: simonis, kvn ! src/cpu/ppc/vm/cppInterpreterGenerator_ppc.hpp ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/templateInterpreterGenerator_ppc.hpp ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp + src/cpu/x86/vm/interpreterGenerator_x86.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b33d97dd6fdc Author: zgu Date: 2014-08-12 12:39 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b33d97dd6fdc 8054938: [TESTBUG] Wrong WhiteBox.java was pushed by JDK-8044140 Summary: Reserved WhiteBox.java pushed by JDK-8044140 Reviewed-by: ccheung, hseigel ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: d3fd2d45ce56 Author: gtriantafill Date: 2014-08-12 14:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d3fd2d45ce56 8054952: [TESTBUG] Add missing NMT2 tests Summary: The new NMT2 tests got lost on the way into jdk9 yesterday, this change adds them. Reviewed-by: coleenp, zgu, ctornqvi + test/runtime/NMT/AutoshutdownNMT.java + test/runtime/NMT/JcmdBaselineDetail.java + test/runtime/NMT/JcmdDetailDiff.java + test/runtime/NMT/JcmdScaleDetail.java + test/runtime/NMT/JcmdSummaryDiff.java + test/runtime/NMT/MallocRoundingReportTest.java + test/runtime/NMT/MallocSiteHashOverflow.java + test/runtime/NMT/MallocStressTest.java + test/runtime/NMT/ReleaseNoCommit.java + test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java Changeset: 8c018e00452f Author: ctornqvi Date: 2014-08-12 21:18 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8c018e00452f Merge - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: 099aef37c20a Author: ctornqvi Date: 2014-08-12 17:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/099aef37c20a 8054713: [TESTBUG] runtime/jsig/Test8017498.sh: Execution failed: exit code 1 Summary: Changed output directory of gcc to avoid permission problems Reviewed-by: coleenp, minqi ! test/runtime/jsig/Test8017498.sh Changeset: c40425f14560 Author: hseigel Date: 2014-08-12 20:29 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c40425f14560 8050485: super() in a try block in a ctor causes VerifyError Summary: Parse catch clause paths to ensure they end in throws Reviewed-by: dlong, acorn, kamg, ctornqvi, lfoltan ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp Changeset: a59f28b051ef Author: hseigel Date: 2014-08-12 21:16 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a59f28b051ef Merge Changeset: d319bc773ea2 Author: dcubed Date: 2014-08-13 13:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d319bc773ea2 Merge ! src/share/vm/memory/collectorPolicy.cpp - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: d5d005f1d973 Author: mgerdin Date: 2014-08-11 17:12 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d5d005f1d973 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot Reviewed-by: kvn, iignatyev, mgerdin Contributed-by: andrey.x.zakharov at oracle.com ! test/compiler/8009761/Test8009761.java ! test/compiler/8010927/Test8010927.java ! test/compiler/arguments/TestUseBMI1InstructionsOnSupportedCPU.java ! test/compiler/arguments/TestUseBMI1InstructionsOnUnsupportedCPU.java ! test/compiler/arguments/TestUseCountLeadingZerosInstructionOnSupportedCPU.java ! test/compiler/arguments/TestUseCountLeadingZerosInstructionOnUnsupportedCPU.java ! test/compiler/arguments/TestUseCountTrailingZerosInstructionOnSupportedCPU.java ! test/compiler/arguments/TestUseCountTrailingZerosInstructionOnUnsupportedCPU.java ! test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java ! test/compiler/intrinsics/bmi/TestAndnI.java ! test/compiler/intrinsics/bmi/TestAndnL.java ! test/compiler/intrinsics/bmi/TestBlsiI.java ! test/compiler/intrinsics/bmi/TestBlsiL.java ! test/compiler/intrinsics/bmi/TestBlsmskI.java ! test/compiler/intrinsics/bmi/TestBlsmskL.java ! test/compiler/intrinsics/bmi/TestBlsrI.java ! test/compiler/intrinsics/bmi/TestBlsrL.java ! test/compiler/intrinsics/bmi/TestLzcntI.java ! test/compiler/intrinsics/bmi/TestLzcntL.java ! test/compiler/intrinsics/bmi/TestTzcntI.java ! test/compiler/intrinsics/bmi/TestTzcntL.java ! test/compiler/intrinsics/bmi/verifycode/AddnTestI.java ! test/compiler/intrinsics/bmi/verifycode/AddnTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsiTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsiTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsmskTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsmskTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsrTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsrTestL.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestL.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestL.java ! test/compiler/intrinsics/mathexact/sanity/AddExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/AddExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java ! test/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java ! test/compiler/rtm/locking/TestRTMAbortRatio.java ! test/compiler/rtm/locking/TestRTMAbortThreshold.java ! test/compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java ! test/compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java ! test/compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java ! test/compiler/rtm/locking/TestRTMLockingCalculationDelay.java ! test/compiler/rtm/locking/TestRTMLockingThreshold.java ! test/compiler/rtm/locking/TestRTMRetryCount.java ! test/compiler/rtm/locking/TestRTMSpinLoopCount.java ! test/compiler/rtm/locking/TestRTMTotalCountIncrRate.java ! test/compiler/rtm/locking/TestUseRTMAfterLockInflation.java ! test/compiler/rtm/locking/TestUseRTMDeopt.java ! test/compiler/rtm/locking/TestUseRTMForInflatedLocks.java ! test/compiler/rtm/locking/TestUseRTMForStackLocks.java ! test/compiler/rtm/locking/TestUseRTMXendForLockBusy.java ! test/compiler/rtm/method_options/TestNoRTMLockElidingOption.java ! test/compiler/rtm/method_options/TestUseRTMLockElidingOption.java ! test/compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! test/compiler/types/correctness/CorrectnessTest.java ! test/compiler/types/correctness/OffTest.java ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/GetNMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestMinInitialErgonomics.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSerialHeapSizeFlags.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java ! test/gc/class_unloading/TestG1ClassUnloadingHWM.java ! test/gc/g1/TestHumongousCodeCacheRoots.java ! test/runtime/ClassUnload/KeepAliveClass.java ! test/runtime/ClassUnload/KeepAliveClassLoader.java ! test/runtime/ClassUnload/KeepAliveObject.java ! test/runtime/ClassUnload/KeepAliveSoftReference.java ! test/runtime/ClassUnload/UnloadTest.java ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/ReleaseCommittedMemory.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/runtime/interned/SanityTest.java ! test/runtime/memory/ReadFromNoaccessArea.java ! test/runtime/memory/ReserveMemory.java ! test/runtime/memory/RunUnitTestsConcurrently.java ! test/runtime/memory/StressVirtualSpaceResize.java ! test/runtime/whitebox/WBStackSize.java ! test/sanity/WBApi.java ! test/sanity/WhiteBox.java ! test/serviceability/ParserTest.java ! test/testlibrary/ctw/test/ClassesDirTest.java ! test/testlibrary/ctw/test/ClassesListTest.java ! test/testlibrary/ctw/test/JarDirTest.java ! test/testlibrary/ctw/test/JarsTest.java ! test/testlibrary_tests/whitebox/vm_flags/BooleanTest.java ! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java ! test/testlibrary_tests/whitebox/vm_flags/StringTest.java ! test/testlibrary_tests/whitebox/vm_flags/Uint64Test.java ! test/testlibrary_tests/whitebox/vm_flags/UintxTest.java Changeset: e0a82e63deef Author: stefank Date: 2014-08-11 14:03 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e0a82e63deef 8054823: Add size_t as a valid VM flag type Reviewed-by: kvn, vlivanov, sla ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/bitMap.cpp + test/gc/arguments/TestArrayAllocatorMallocLimit.java + test/serviceability/attach/AttachSetGetFlag.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary_tests/whitebox/vm_flags/SizeTTest.java Changeset: 34d40fa9d0f2 Author: jmasa Date: 2014-08-14 18:42 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/34d40fa9d0f2 Merge ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/management.cpp - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/ReleaseCommittedMemory.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 7a0fe19ac034 Author: amurillo Date: 2014-08-15 09:19 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7a0fe19ac034 Merge - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: 8e575cec7af9 Author: amurillo Date: 2014-08-19 11:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8e575cec7af9 Merge ! src/share/vm/runtime/os.cpp - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: 657294869d7f Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/657294869d7f Merge - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: 0050efd213f1 Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0050efd213f1 Added tag jdk9-b28 for changeset 657294869d7f ! .hgtags Changeset: 16286b7d7c6e Author: iklam Date: 2014-08-12 17:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/16286b7d7c6e 8046070: Class Data Sharing clean up and refactoring Summary: Cleaned up CDS to be more configurable, maintainable and extensible Reviewed-by: dholmes, coleenp, acorn, mchung ! make/excludeSrc.make ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp + src/share/vm/classfile/classLoaderExt.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp + src/share/vm/classfile/sharedClassUtil.hpp + src/share/vm/classfile/sharedPathsMiscInfo.cpp + src/share/vm/classfile/sharedPathsMiscInfo.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp + src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + src/share/vm/utilities/stringUtils.cpp + src/share/vm/utilities/stringUtils.hpp + test/testlibrary/com/oracle/java/testlibrary/BuildHelper.java Changeset: 72030160367a Author: zgu Date: 2014-08-14 09:02 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/72030160367a 8054368: nsk/jdi/VirtualMachine/exit/exit002 crash with detail tracking on (NMT2) Summary: Dynamic allocate _reserved_regions instead of static object to avoid racing during process exit Reviewed-by: dholmes, coleenp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/virtualMemoryTracker.cpp ! src/share/vm/services/virtualMemoryTracker.hpp Changeset: 8a290a0d2153 Author: zgu Date: 2014-08-14 13:13 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8a290a0d2153 Merge Changeset: 01e6096da640 Author: zgu Date: 2014-08-14 13:15 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/01e6096da640 8054547: Re-enable warning for incompatible java launcher Summary: Re-enabled warning as launcher change reached promotion build Reviewed-by: hseigel, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 4a937a64c20b Author: zgu Date: 2014-08-14 17:25 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4a937a64c20b Merge ! src/share/vm/runtime/arguments.cpp Changeset: 80b831308478 Author: ctornqvi Date: 2014-08-14 18:14 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/80b831308478 8032999: [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job Summary: JPRT will now run most of the tests in /runtime Reviewed-by: dcubed, mseledtsov, zgu, mikael ! make/jprt.properties ! test/TEST.groups ! test/runtime/7158988/FieldMonitor.java ! test/runtime/CompressedOops/CompressedClassPointers.java ! test/runtime/jsig/Test8017498.sh Changeset: af24453bcd3e Author: sspitsyn Date: 2014-08-15 11:25 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/af24453bcd3e Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ce9fb9e64334 Author: coleenp Date: 2014-08-15 15:25 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ce9fb9e64334 8055231: ZERO variant build is broken Summary: Fix zero build. Reviewed-by: coleenp Contributed-by: Severin Gehwolf ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 03b8d901bdea Author: coleenp Date: 2014-08-15 20:37 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/03b8d901bdea Merge Changeset: c346a7739aee Author: zgu Date: 2014-08-19 08:34 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c346a7739aee 8055007: NMT2: emptyStack missing in minimal build Summary: Refactored emptyStack to a static member of NativeCallStack, which is accessible in minimal build. Reviewed-by: coleenp, dholmes ! src/share/vm/services/mallocSiteTable.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/nmtCommon.hpp ! src/share/vm/services/virtualMemoryTracker.cpp ! src/share/vm/services/virtualMemoryTracker.hpp ! src/share/vm/utilities/nativeCallStack.cpp ! src/share/vm/utilities/nativeCallStack.hpp Changeset: 83b971c5423f Author: zgu Date: 2014-08-19 08:42 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/83b971c5423f Merge ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/virtualMemoryTracker.cpp ! src/share/vm/services/virtualMemoryTracker.hpp Changeset: c041b65beeed Author: zgu Date: 2014-08-19 09:05 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c041b65beeed 8055061: assert at share/vm/services/virtualMemoryTracker.cpp:332 Error: ShouldNotReachHere() when running NMT tests Summary: Handled CDS mapping region and added test for the scenario Reviewed-by: coleenp, ctornqvi ! src/share/vm/services/virtualMemoryTracker.cpp + test/runtime/NMT/NMTWithCDS.java Changeset: e6122e00c927 Author: gtriantafill Date: 2014-08-18 11:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e6122e00c927 8054711: [TESTBUG] Enable NMT2 tests after NMT2 is integrated Summary: enable tests for NMT2 Reviewed-by: ctornqvi, zgu ! test/runtime/NMT/AutoshutdownNMT.java ! test/runtime/NMT/BaselineWithParameter.java ! test/runtime/NMT/CommandLineDetail.java ! test/runtime/NMT/CommandLineEmptyArgument.java ! test/runtime/NMT/CommandLineInvalidArgument.java ! test/runtime/NMT/CommandLineSummary.java ! test/runtime/NMT/CommandLineTurnOffNMT.java ! test/runtime/NMT/JcmdBaselineDetail.java ! test/runtime/NMT/JcmdScale.java ! test/runtime/NMT/JcmdScaleDetail.java ! test/runtime/NMT/JcmdSummaryDiff.java ! test/runtime/NMT/JcmdWithNMTDisabled.java ! test/runtime/NMT/MallocRoundingReportTest.java ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java ! test/runtime/NMT/ReleaseCommittedMemory.java ! test/runtime/NMT/ReleaseNoCommit.java ! test/runtime/NMT/ShutdownTwice.java ! test/runtime/NMT/SummaryAfterShutdown.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java Changeset: 56ff43213a78 Author: gtriantafill Date: 2014-08-19 06:47 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/56ff43213a78 8055051: runtime/NMT/CommandLineEmptyArgument.java fails Summary: disable failing test Reviewed-by: ctornqvi, zgu ! test/runtime/NMT/CommandLineEmptyArgument.java Changeset: b808a03aa0b7 Author: zgu Date: 2014-08-19 10:04 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b808a03aa0b7 Merge ! src/share/vm/services/virtualMemoryTracker.cpp ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/ReleaseCommittedMemory.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java Changeset: 0ade41b2dbeb Author: jmasa Date: 2013-11-21 09:57 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0ade41b2dbeb 8026303: CMS: JVM intermittently crashes with "FreeList of size 258 violates Conservation Principle" assert Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 5997ed0b2734 Author: jmasa Date: 2014-08-15 09:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5997ed0b2734 Merge Changeset: f9a1351ded4f Author: stefank Date: 2014-08-18 14:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f9a1351ded4f 8055275: Several gc/class_unloading/ tests fail due to missed +UnlockDiagnosticVMOptions flag Reviewed-by: mgerdin, jwilhelm ! test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java ! test/gc/class_unloading/TestG1ClassUnloadingHWM.java Changeset: 057a2501eb5f Author: stefank Date: 2014-08-18 12:25 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/057a2501eb5f Merge - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: 06c4ab3d220b Author: tschatzl Date: 2014-08-18 15:41 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/06c4ab3d220b 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java timeout Summary: Give the test a time limit of approximately one minute so that it exits early on slow machines. Reviewed-by: ehelin, dfazunen, brutisso ! test/gc/g1/TestEagerReclaimHumongousRegions2.java Changeset: 1662147c9ca3 Author: mgerdin Date: 2014-08-18 16:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1662147c9ca3 8055284: sanity/WhiteBox.java fails with NPE Summary: Revert previous change, sanity/WhiteBox.java provides its own sun.hotspot.WhiteBox class. Reviewed-by: ehelin, brutisso Contributed-by: dmitry.fazunenko at oracle.com ! test/sanity/WhiteBox.java Changeset: 724693e4412d Author: mgerdin Date: 2014-08-18 14:49 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/724693e4412d Merge Changeset: 6c9cd9128efb Author: tschatzl Date: 2014-08-18 16:10 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6c9cd9128efb 8054818: Refactor HeapRegionSeq to manage heap region and auxiliary data Summary: Let HeapRegionSeq manage the heap region and auxiliary data to decrease the amount of responsibilities of G1CollectedHeap, and encapsulate this work from other code. Reviewed-by: jwilhelm, jmasa, mgerdin, brutisso ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/whitebox.cpp Changeset: 92d550c8f10b Author: tschatzl Date: 2014-08-18 15:43 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/92d550c8f10b Merge Changeset: 8cf8b0ab1b08 Author: poonam Date: 2014-08-18 19:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8cf8b0ab1b08 8044406: JVM crash with JDK8 (build 1.8.0-b132) with G1 GC Summary: Fill the last card that has been allocated into with a dummy object Reviewed-by: tschatzl, mgerdin ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 8985af9b3519 Author: tschatzl Date: 2014-08-19 14:09 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8985af9b3519 8038423: G1: Decommit memory within heap Summary: Allow G1 to decommit memory of arbitrary regions within the heap and their associated auxiliary data structures card table, BOT, hot card cache, and mark bitmaps. Reviewed-by: mgerdin, brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1HotCardCache.cpp ! src/share/vm/gc_implementation/g1/g1HotCardCache.hpp + src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp + src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.hpp + src/share/vm/gc_implementation/g1/g1RegionToSpaceMapper.cpp + src/share/vm/gc_implementation/g1/g1RegionToSpaceMapper.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/prims/jni.cpp Changeset: d5101d894b87 Author: jmasa Date: 2014-08-19 13:44 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d5101d894b87 Merge Changeset: 73561302492c Author: tschatzl Date: 2014-08-20 14:34 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/73561302492c 8055525: Bigapp weblogic+medrec fails to startup after JDK-8038423 Summary: If large pages are enabled and configured in Linux, the VM always pre-commits the entire space. The VM fails verification of the commit of the initial heap because some internal data structure marked all memory pages of the heap as committed during initialization. This makes the code think that we attempted a double-commit during first allocation of the heap. Remove the initial marking of memory pages of the heap to committed. Reviewed-by: mgerdin ! src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp Changeset: d617b298b734 Author: tschatzl Date: 2014-08-20 15:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d617b298b734 8055635: Missing include in g1RegionToSpaceMapper.hpp results in unresolved symbol of fastdebug build without precompiled headers Reviewed-by: mgerdin, ehelin ! src/share/vm/gc_implementation/g1/g1RegionToSpaceMapper.cpp ! src/share/vm/gc_implementation/g1/g1RegionToSpaceMapper.hpp Changeset: 73cf3098bd73 Author: jmasa Date: 2014-08-21 10:51 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/73cf3098bd73 Merge Changeset: 954700ff3322 Author: thartmann Date: 2014-08-11 13:01 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/954700ff3322 8043284: Optimize signed integer comparison Summary: Folding of BoolNode if input add/sub of CmpI overflows and we can prove that compared value is not in the two resulting ranges. Added test for CmpI and CmpU optimizations. Reviewed-by: kvn, rbackman, roland ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp + test/compiler/IntegerArithmetic/TestIntegerComparison.java Changeset: 190b0e9d0ad1 Author: roland Date: 2014-08-11 14:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/190b0e9d0ad1 7173584: Implement arraycopy as a macro node Summary: delay the conversion of arraycopy to stub calls to macro expansion Reviewed-by: kvn, iveresov ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp + src/share/vm/opto/macroArrayCopy.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.hpp Changeset: db7d2f27bcb6 Author: roland Date: 2014-08-11 13:02 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/db7d2f27bcb6 Merge Changeset: 99995cb1ae44 Author: anoll Date: 2014-08-13 10:44 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/99995cb1ae44 8043913: remove legacy code in SPARC's VM_Version::platform_features Summary: Kept only getisax(2) to determine platform features Reviewed-by: kvn, roland Contributed-by: Zoltan Majo ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: 7f427b4f174d Author: roland Date: 2014-08-11 15:09 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7f427b4f174d 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError Summary: do not update exception cache if exception is replaced when thrown Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_Runtime1.cpp + test/compiler/exceptions/TestRecursiveReplacedException.java Changeset: 3d0f5e4b3eec Author: roland Date: 2014-08-13 09:53 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3d0f5e4b3eec Merge Changeset: f62b69773aaf Author: kvn Date: 2014-08-13 13:05 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f62b69773aaf 8054927: Missing MemNode::acquire ordering in some volatile Load nodes Summary: Fixed memory ordering parameter and added missing barriers for volatile loads. Reviewed-by: roland, iveresov ! src/share/vm/opto/library_call.cpp Changeset: 4395c63e455b Author: mduigou Date: 2014-08-13 23:33 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4395c63e455b 8047952: Remove _FORTIFY_SOURCE from fastdebug and slowdebug builds Reviewed-by: dholmes ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: 1d600d0306c6 Author: iveresov Date: 2014-08-13 17:37 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1d600d0306c6 8054883: Segmentation error while running program Summary: Fix pattern matching of range check Reviewed-by: kvn ! src/share/vm/opto/ifnode.cpp Changeset: cf3ccda01fa6 Author: thartmann Date: 2014-08-14 09:15 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cf3ccda01fa6 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes Summary: Because anonymous classes are not in the system dictionary, we have to set 'unloading_occurred' based on 'CLDG::do_unloading()'. Added jtreg test. Reviewed-by: kvn, coleenp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp + test/compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java Changeset: c3616819585c Author: kvn Date: 2014-08-15 12:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c3616819585c Merge ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/opto/compile.cpp Changeset: 7c8d05c88072 Author: thartmann Date: 2014-08-19 07:36 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7c8d05c88072 8048879: "unexpected yanked node" opto/postaloc.cpp:139 Summary: MemBarAcquireNode prevents deletion of dead LoadNNode. Added condition to 'has_special_unique_user' to trigger deletion. Reviewed-by: kvn, iveresov ! src/share/vm/opto/node.cpp + test/compiler/membars/TestMemBarAcquire.java Changeset: ae92f23ff97a Author: kvn Date: 2014-08-13 17:50 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ae92f23ff97a 8054164: solaris makefile Reviewed-by: roland ! make/solaris/makefiles/dtrace.make Changeset: d70e26dc1712 Author: kvn Date: 2014-08-19 17:48 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d70e26dc1712 Merge - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp Changeset: bcfc31be2968 Author: kvn Date: 2014-08-19 16:20 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bcfc31be2968 8055503: Rollback 8054164 changeset Reviewed-by: iveresov ! make/solaris/makefiles/dtrace.make Changeset: 29999b8709a4 Author: roland Date: 2014-08-19 17:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/29999b8709a4 8055153: nsk/stress/jck60/jck60014 crashes on sparc Summary: missing control for LoadRange and LoadKlass nodes created during arraycopy node expansion Reviewed-by: kvn, iveresov ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macroArrayCopy.cpp + test/compiler/arraycopy/TestMissingControl.java Changeset: 865c90cfd688 Author: rbackman Date: 2014-08-21 20:24 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/865c90cfd688 Merge ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 44776dc0edd9 Author: rbackman Date: 2014-08-21 19:06 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/44776dc0edd9 Merge Changeset: bf4d2f5595bc Author: tschatzl Date: 2014-08-21 16:44 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bf4d2f5595bc 8055098: WB API should be extended to provide information about size and age of object. Summary: Extend the WhiteBox API to provide information about the size and age of objects. Further add a mechanism to trigger a young GC. Reviewed-by: tschatzl, sjohanss Contributed-by: Leonid Mesnik ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/prims/whitebox.cpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 3356b614acfa Author: jmasa Date: 2014-08-22 07:12 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3356b614acfa Merge Changeset: 41fa2928807a Author: amurillo Date: 2014-08-22 09:55 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/41fa2928807a Merge Changeset: deb29e92f68a Author: lana Date: 2014-08-29 11:57 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/deb29e92f68a Merge Changeset: 79a01e915f52 Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/79a01e915f52 Added tag jdk9-b29 for changeset deb29e92f68a ! .hgtags Changeset: 91f25b8a47af Author: zgu Date: 2014-08-20 08:41 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/91f25b8a47af 8054546: NMT2 leaks memory Summary: Fixed memory leak in NMT by baselining memory in c heap instead of an arena. Reviewed-by: coleenp, minqi ! src/share/vm/services/mallocTracker.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp Changeset: 6ae3b7da7952 Author: zgu Date: 2014-08-20 08:50 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6ae3b7da7952 Merge Changeset: f2417008f618 Author: zgu Date: 2014-08-20 15:58 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f2417008f618 8055236: Deadlock during NMT2 shutdown on Windows Summary: Removed MemTracker::shutdown() call to avoid deadlock Reviewed-by: minqi, ctornqvi ! src/os/windows/vm/os_windows.cpp Changeset: 115d958b07de Author: zgu Date: 2014-08-20 21:37 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/115d958b07de Merge Changeset: 943c5da523fd Author: ctornqvi Date: 2014-08-20 14:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/943c5da523fd 8055164: [TESTBUG] runtime/CompressedOops/CompressedClassPointers.java fails with OpenJDK build Summary: Removed explicit check for HotSpot in output Reviewed-by: sla, coleenp, hseigel ! test/runtime/CompressedOops/CompressedClassPointers.java Changeset: 23270ceb0be7 Author: ctornqvi Date: 2014-08-20 14:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/23270ceb0be7 8027480: Build Windows x64 fastdebug builds using /homeparams Summary: Windows x64 fastdebug builds now uses the /homeparams compiler flag Reviewed-by: dcubed, zgu, lfoltan ! make/windows/makefiles/vm.make ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC8.java Changeset: b231e0ef5547 Author: ctornqvi Date: 2014-08-21 01:43 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b231e0ef5547 Merge Changeset: af72c1a537dc Author: igerasim Date: 2014-08-21 16:32 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/af72c1a537dc 8055338: (process) Add instrumentation to help diagnose JDK-6573254 Reviewed-by: dcubed, ohair, iklam, dholmes, sspitsyn, sla ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/java.cpp Changeset: f7df20ae08e2 Author: sla Date: 2014-08-22 08:13 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f7df20ae08e2 8055754: filemap.cpp does not compile with clang Reviewed-by: kvn, iklam, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp Changeset: b5c908c4e997 Author: ctornqvi Date: 2014-08-22 09:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b5c908c4e997 8055814: [TESTBUG] runtime/NMT/NMTWithCDS.java fails with product builds due to missing UnlockDiagnosticVMOptions Summary: Passing -XX:+UnlockDiagnosticVMOptions to ProcessBuilder Reviewed-by: zgu, gtriantafill ! test/runtime/NMT/NMTWithCDS.java Changeset: 6c4b3632b42f Author: dcubed Date: 2014-08-22 11:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6c4b3632b42f Merge Changeset: 8519a5cf7cd4 Author: gtriantafill Date: 2014-08-22 06:46 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8519a5cf7cd4 8055052: [TESTBUG] runtime/NMT/JcmdDetailDiff.java fails on Windows when there are no debug symbols available Reviewed-by: ctornqvi, hseigel ! test/runtime/NMT/JcmdDetailDiff.java Changeset: d764332b3890 Author: gtriantafill Date: 2014-08-22 07:38 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d764332b3890 8055053: [TESTBUG] runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails Reviewed-by: ctornqvi, zgu ! test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java Changeset: 2d87b6b4660c Author: gtriantafill Date: 2014-08-21 14:37 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2d87b6b4660c 8055684: runtime/NMT/CommandLineEmptyArgument.java fails Reviewed-by: ctornqvi, sla ! test/runtime/NMT/CommandLineEmptyArgument.java Changeset: 04b4bc792043 Author: gtriantafill Date: 2014-08-22 06:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/04b4bc792043 8055765: Misplaced @key stress prevents MallocSiteHashOverflow.java and MallocStressTest.java tests from running Reviewed-by: ctornqvi, zgu, hseigel ! test/runtime/NMT/MallocSiteHashOverflow.java ! test/runtime/NMT/MallocStressTest.java Changeset: 026e9d17ba9b Author: ctornqvi Date: 2014-08-22 14:21 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/026e9d17ba9b 8055844: [TESTBUG] test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails on Solaris Sparc due to incorrect page size being used Summary: Use 128KB chunks for virtual memory operations Reviewed-by: zgu, gtriantafill ! test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java Changeset: 86451b926286 Author: ccheung Date: 2014-08-25 00:13 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/86451b926286 8048150: Allow easy configurations for large CDS archives Summary: Estimate the size of shared archive based on the number of classes in the classlist file Reviewed-by: iklam, jiangli, minqi, dholmes ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp Changeset: 8ae56f4f758f Author: ctornqvi Date: 2014-08-26 13:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8ae56f4f758f 8041727: [TESTBUG] runtime/jsig/Test8017498.sh fails with Test8017498.sh: 50: [: x/usr/bin/gcc: unexpected operator Summary: Fixed shell script issues Reviewed-by: dcubed, gtriantafill ! test/runtime/jsig/Test8017498.sh Changeset: 820608bf2902 Author: kvn Date: 2014-08-22 12:03 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/820608bf2902 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected Summary: Require to specify UnlockExperimentalVMOptions flag together with UseRTMLocking flag on un-patched systems where CPUID allows it but is unsupported otherwise. Reviewed-by: iveresov, fzhinkin ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! test/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java Changeset: b7cadec70148 Author: thartmann Date: 2014-08-25 07:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b7cadec70148 8055751: TestAnonymousClassUnloading.java needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot Summary: Copy additional Whitebox class file to JTwork (required by JDK-8011397). Reviewed-by: kvn ! test/compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java Changeset: 3ce2966392ef Author: thartmann Date: 2014-08-25 07:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3ce2966392ef 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC Summary: Remove the '-XX:+UseParallelGC' parameter from the test because it is conflicting with other GC settings. Reviewed-by: kvn ! test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java Changeset: 03792046279f Author: thartmann Date: 2014-08-25 07:44 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/03792046279f Merge Changeset: 09bd266452ee Author: zmajo Date: 2014-08-27 10:02 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/09bd266452ee 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory Summary: Change memory allocation in TypeTuple::make_domain() and TypeTuple::make_range() to not allocate memory for TypeFunc::Parms. Reviewed-by: kvn, roland ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 3c92cbe3250f Author: iignatyev Date: 2014-08-27 17:09 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3c92cbe3250f 8056072: add jprt_optimized targets Reviewed-by: kvn, roland ! make/Makefile ! make/jprt.gmk ! make/jprt.properties Changeset: 6a88438902fb Author: rbackman Date: 2014-08-28 18:31 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6a88438902fb Merge Changeset: c9f4b775ec14 Author: brutisso Date: 2014-08-25 08:27 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c9f4b775ec14 8055818: Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp Changeset: 73f74a485368 Author: stefank Date: 2014-08-25 09:10 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/73f74a485368 8055416: Several vm/gc/heap/summary "After GC" events emitted for the same GC ID Reviewed-by: brutisso, ehelin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 8ef8e5c997cc Author: stefank Date: 2014-08-25 07:35 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8ef8e5c997cc Merge Changeset: 7808b2d5d604 Author: tschatzl Date: 2014-08-26 09:36 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7808b2d5d604 8054819: Rename HeapRegionSeq to HeapRegionManager Reviewed-by: jwilhelm, jmasa ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionManager.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp + src/share/vm/gc_implementation/g1/heapRegionManager.cpp + src/share/vm/gc_implementation/g1/heapRegionManager.hpp + src/share/vm/gc_implementation/g1/heapRegionManager.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp Changeset: 6227e3d7a5b6 Author: jmasa Date: 2014-08-28 08:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6227e3d7a5b6 Merge Changeset: 3e66f85c4b33 Author: jmasa Date: 2014-08-28 17:45 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3e66f85c4b33 Merge - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java - src/share/vm/gc_implementation/g1/heapRegionSeq.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp Changeset: 0a92f32c3883 Author: tschatzl Date: 2014-08-26 14:15 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0a92f32c3883 8055953: [TESTBUG] Fix for 8055098 does not contain unit test Summary: Add missing unit test. Reviewed-by: tschatzl Contributed-by: Leonid Mesnik + test/gc/whitebox/TestWBGC.java Changeset: fc146c1f9594 Author: tschatzl Date: 2014-08-26 14:15 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fc146c1f9594 8055919: Remove dead code in G1 concurrent marking code Reviewed-by: jmasa, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: 8024c15868c8 Author: tschatzl Date: 2014-08-27 08:59 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8024c15868c8 8056043: Heap does not shrink within the heap after JDK-8038423 Summary: Enable shrinking within the heap by removing some code added for JDK-8054818. Enable the test case that checks that again too. Reviewed-by: jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/heapRegionManager.cpp ! test/gc/g1/TestHumongousShrinkHeap.java Changeset: 9c6176aa57b9 Author: brutisso Date: 2014-08-27 10:51 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9c6176aa57b9 8055816: Remove dead code in g1BlockOffsetTable Reviewed-by: tschatzl, mgerdin ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 48de4d583857 Author: brutisso Date: 2014-08-27 09:22 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/48de4d583857 Merge Changeset: 14c813b8ba20 Author: sjohanss Date: 2014-08-27 09:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/14c813b8ba20 8028787: tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02 fails nsk.share.Failure: OGC < OGCMN in RT_Baseline Summary: Passing the min and max size of the generation into the counter instead of using the space to estimate sizes. Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/tenuredGeneration.cpp Changeset: 2c2fbe2d095a Author: jmasa Date: 2014-08-28 11:25 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2c2fbe2d095a Merge Changeset: 647c1493f833 Author: tschatzl Date: 2014-08-28 17:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/647c1493f833 8054808: Bitmap verification sometimes fails after Full GC aborts concurrent mark. Summary: The verification code that checked whether no bitmap mark had been found re-read HeapRegion::end() after the check on the bitmap. Concurrent humongous object allocation could have changed HeapRegion::end() in the meantime. Fix this by using the actual end of the region instead of HeapRegion::end() for comparison. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: fb7e346a0f3f Author: jmasa Date: 2014-08-29 08:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fb7e346a0f3f Merge ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: b515190809d5 Author: dfazunen Date: 2014-08-28 18:38 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b515190809d5 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources Reviewed-by: jmasa ! test/gc/g1/TestStringDeduplicationTools.java Changeset: 40c22d6c0cef Author: tschatzl Date: 2014-08-28 17:06 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/40c22d6c0cef Merge ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: aa64b1cbb1b8 Author: tschatzl Date: 2014-08-28 15:55 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/aa64b1cbb1b8 Merge Changeset: 1a3bdc233bda Author: jmasa Date: 2014-08-29 08:14 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1a3bdc233bda Merge Changeset: 5c722dffbc0f Author: lana Date: 2014-09-04 14:45 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5c722dffbc0f Merge Changeset: efe1eb043ee1 Author: katleman Date: 2014-09-11 09:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/efe1eb043ee1 Added tag jdk9-b30 for changeset 5c722dffbc0f ! .hgtags Changeset: dc1a065e6989 Author: ccheung Date: 2014-08-27 10:42 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dc1a065e6989 8056175: Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC Summary: cast the result of the conversion to uintx Reviewed-by: ccheung, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/memory/metaspaceShared.hpp Changeset: fe13911efa5b Author: sla Date: 2014-08-28 10:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fe13911efa5b 8055755: Information about loaded dynamic libraries is wrong on MacOSX Summary: The information about loaded dynamic libraries printed in hs_err_pid files or by running the jcmd VM.dynlib is partly incorrect. The address printed in front of the library file name is wrong. Reviewed-by: sla, gziemski, gtriantafill Contributed-by: fredrik.arvidsson at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: 92bc0d7679a7 Author: dsamersoff Date: 2014-08-28 06:32 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/92bc0d7679a7 8031583: warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending Summary: Added missed exception checks Reviewed-by: sla, sspitsyn ! agent/src/os/solaris/proc/saproc.cpp Changeset: 68e9f36fd6c8 Author: dsamersoff Date: 2014-08-28 07:46 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/68e9f36fd6c8 8029172: warnings from b117 for hotspot.agent.src.os.linux: JNI exception pending Summary: Added missed exception checks Reviewed-by: chegar, sla ! agent/src/os/linux/LinuxDebuggerLocal.c Changeset: 4acab3118361 Author: coleenp Date: 2014-08-28 11:29 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4acab3118361 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) Summary: This removes component mirrors from arrayKlass metadata and the C2 intrinsic for them. Reviewed-by: kvn, twisti, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! make/aix/makefiles/mapfile-vers-debug ! make/aix/makefiles/mapfile-vers-product ! make/bsd/makefiles/mapfile-vers-darwin-debug ! make/bsd/makefiles/mapfile-vers-darwin-product ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6e55d72da10c Author: coleenp Date: 2014-08-28 11:30 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6e55d72da10c Merge Changeset: fca0e8790cca Author: coleenp Date: 2014-08-28 15:44 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fca0e8790cca Merge Changeset: 920134274861 Author: lfoltan Date: 2014-08-28 11:56 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/920134274861 8054355: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for JDK 9. Summary: Update of C++ validiation check for JDK 9 on Solaris. Reviewed-by: coleenp, dcubed, kvn ! make/solaris/makefiles/sparcWorks.make Changeset: 34f2b1c63639 Author: lfoltan Date: 2014-08-28 13:01 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/34f2b1c63639 Merge Changeset: c8238a5aa66a Author: sla Date: 2014-08-29 13:34 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c8238a5aa66a 8055838: Hotspot does not compile with clang 6.0 (OS X Yosemite) Reviewed-by: lfoltan, kvn ! make/bsd/makefiles/gcc.make Changeset: 2e3b1aa376cc Author: sspitsyn Date: 2014-08-29 11:35 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2e3b1aa376cc Merge Changeset: 9cfb26e195ac Author: iklam Date: 2014-09-02 09:51 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9cfb26e195ac 8056971: Minor class loading clean-up Summary: Misplacement of #if INCLUE_CDS, typos, unnecessary C string duplication Reviewed-by: dholmes, ccheung ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderExt.hpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/classfile/sharedPathsMiscInfo.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 04760b64fe35 Author: ctornqvi Date: 2014-09-03 17:30 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/04760b64fe35 8057147: [TESTBUG] Platform.isDebugBuild() doesn't work on all build types Summary: Check java.version for debug string as well Reviewed-by: gtriantafill, hseigel, sla, acorn, dcubed ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: f80bb126b5bb Author: mgerdin Date: 2014-08-29 13:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f80bb126b5bb 8056084: Refactor Hashtable to allow implementations without rehashing support Reviewed-by: gziemski, jmasa, brutisso, coleenp, tschatzl ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/stringTable.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 0517bedd0d58 Author: mgerdin Date: 2014-08-29 13:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0517bedd0d58 8048268: G1 Code Root Migration performs poorly Summary: Replace G1CodeRootSet with a Hashtable based implementation, merge Code Root Migration phase into Code Root Scanning Reviewed-by: jmasa, brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp ! src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/utilities/hashtable.cpp Changeset: cc5a4555c40d Author: stefank Date: 2014-09-03 12:45 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cc5a4555c40d 8057037: Verification in ClassLoaderData::is_alive is too slow Reviewed-by: brutisso, mgerdin, tschatzl ! src/share/vm/classfile/classLoaderData.cpp Changeset: 5542c5da9622 Author: tschatzl Date: 2014-09-03 17:01 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5542c5da9622 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq Summary: Fixup the remaining variable names. Reviewed-by: tonyp, jwilhelm ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 3f41fe2dbb85 Author: tschatzl Date: 2014-09-03 15:07 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3f41fe2dbb85 Merge Changeset: 9f4c8b92cb95 Author: jmasa Date: 2014-09-04 12:25 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9f4c8b92cb95 Merge Changeset: bc623e36f874 Author: jmasa Date: 2014-09-04 13:45 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bc623e36f874 Merge Changeset: 132677ca8e4e Author: iignatyev Date: 2014-08-28 23:30 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/132677ca8e4e 8056223: typo in export_optimized_jdk Reviewed-by: kvn ! make/Makefile Changeset: 949cc7926b7e Author: thartmann Date: 2014-08-29 14:46 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/949cc7926b7e 8056067: NodeHash debug variables are available in product build Summary: Make NodeHash debug variables only available in debug/optimized build. Reviewed-by: kvn, roland ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: 5cb3c079bf70 Author: zmajo Date: 2014-08-29 15:32 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5cb3c079bf70 8055286: Extend CompileCommand=option to handle numeric parameters Summary: Changed CompileCommand=option to handle "extended" parameters: Klass::method,type,flag,value. Types supported are bool, intx, and uintx. Reviewed-by: kvn, roland ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp Changeset: 3a2d373abcab Author: thartmann Date: 2014-08-29 13:46 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3a2d373abcab Merge Changeset: bb102ba0100f Author: drchase Date: 2014-08-29 19:45 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bb102ba0100f 8054292: code comments leak in fastdebug builds Summary: Added deallocation to destructor; hardened interface against misuse Reviewed-by: kvn ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/interpreter.hpp Changeset: a9581f019c38 Author: kvn Date: 2014-09-02 10:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a9581f019c38 8056964: JDK-8055286 changes are incomplete. Summary: added ccstr and ccstrlist types to compilerOracle 'option' command Reviewed-by: roland ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/compile.hpp Changeset: 427de14928ab Author: kvn Date: 2014-09-02 12:48 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/427de14928ab 8055494: Add C2 x86 intrinsic for BigInteger::multiplyToLen() method Summary: Add new C2 intrinsic for BigInteger::multiplyToLen() on x86 in 64-bit VM. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/multiplytolen/TestMultiplyToLen.java Changeset: 4b78b9dddd05 Author: roland Date: 2014-08-29 16:32 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4b78b9dddd05 8055910: closed/java/util/Collections/CheckedCollections.java failed with ClassCastException not thrown Summary: missing subtype check for Arrays.copyOf intrinsic Reviewed-by: kvn, iveresov ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macroArrayCopy.cpp ! src/share/vm/opto/memnode.cpp + test/compiler/arraycopy/TestArrayOfNoTypeCheck.java Changeset: df76aa0bf77f Author: roland Date: 2014-08-27 17:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/df76aa0bf77f 8055946: assert(result == NULL || result->is_oop()) failed: must be oop Summary: caller of popped frame doesn't have valid result during deoptimization Reviewed-by: kvn ! src/share/vm/runtime/deoptimization.cpp Changeset: a274904ceb95 Author: fzhinkin Date: 2014-09-03 15:24 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a274904ceb95 8056091: Move compiler/intrinsics/mathexact/sanity/Verifier to compiler/testlibrary and extend its functionality Reviewed-by: kvn, iignatyev ! test/compiler/intrinsics/mathexact/sanity/AddExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/AddExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/IntrinsicBase.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java - test/compiler/intrinsics/mathexact/sanity/Verifier.java + test/compiler/testlibrary/intrinsics/Verifier.java Changeset: 846fc505810a Author: fzhinkin Date: 2014-09-03 15:26 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/846fc505810a 8055903: Develop sanity tests on SPARC's SHA instructions support Reviewed-by: kvn, iignatyev + test/compiler/intrinsics/sha/sanity/SHASanityTestBase.java + test/compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java + test/compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java + test/compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java + test/compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java + test/compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java + test/compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java + test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java Changeset: 676f67452a76 Author: fzhinkin Date: 2014-09-03 15:29 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/676f67452a76 8055904: Develop tests for new command-line options related to SHA intrinsics Reviewed-by: kvn, iignatyev + test/compiler/intrinsics/sha/cli/SHAOptionsBase.java + test/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java + test/compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java + test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForOtherCPU.java + test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedSparcCPU.java + test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedSparcCPU.java + test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedX86CPU.java + test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedSparcCPU.java + test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java + test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedSparcCPU.java Changeset: 5a313cfb5637 Author: roland Date: 2014-08-02 06:15 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5a313cfb5637 8057038: Speculative traps not robust when compilation and class unloading are concurrent Summary: speculative traps can be removed from MDO while being copied by compiler Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: cbae7c62e1bd Author: simonis Date: 2014-09-03 14:39 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cbae7c62e1bd 8057129: Fix AIX build after the Extend CompileCommand=option change 8055286 Reviewed-by: kvn ! src/share/vm/compiler/compilerOracle.cpp Changeset: 624c017f6d94 Author: kvn Date: 2014-09-04 22:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/624c017f6d94 Merge - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: efb715d3f337 Author: lana Date: 2014-09-10 19:36 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/efb715d3f337 Merge - test/compiler/intrinsics/mathexact/sanity/Verifier.java Changeset: efd9baea1186 Author: wetmore Date: 2014-09-11 12:18 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/efd9baea1186 8058180: .hgignore should be updated with webrev in all repos Reviewed-by: jrose, katleman, jjg ! .hgignore Changeset: 9f7d155d28e5 Author: lana Date: 2014-09-11 14:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9f7d155d28e5 Merge - test/compiler/intrinsics/mathexact/sanity/Verifier.java Changeset: 49d1d18d24d6 Author: katleman Date: 2014-09-17 22:55 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/49d1d18d24d6 Added tag jdk9-b31 for changeset 9f7d155d28e5 ! .hgtags Changeset: 6818c5298fab Author: dholmes Date: 2014-09-02 21:27 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6818c5298fab 8046210: Missing memory barrier when reading init_lock Reviewed-by: fparain, dcubed, mdoerr Contributed-by: Bill Pittore ! src/share/vm/oops/instanceKlass.cpp Changeset: 20c8773305b1 Author: sla Date: 2014-09-03 14:43 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/20c8773305b1 8056242: Add function to return structured information about loaded libraries. Summary: Return structured information about loaded libraries. Reviewed-by: sla, dsamersoff Contributed-by: fredrik.arvidsson at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: e3fb51ae8d7d Author: coleenp Date: 2014-09-03 19:13 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e3fb51ae8d7d 8055008: Clean up code that saves the previous versions of redefined classes Summary: Use scratch_class to find EMCP methods for breakpoints if the old methods are still running. Reviewed-by: dcubed, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp - test/runtime/RedefineFinalizer/RedefineFinalizer.java + test/runtime/RedefineTests/RedefineFinalizer.java + test/runtime/RedefineTests/RedefineRunningMethods.java Changeset: 0c68d517f7ec Author: sla Date: 2014-09-04 08:48 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0c68d517f7ec Merge - test/runtime/RedefineFinalizer/RedefineFinalizer.java Changeset: c770a9cc2f86 Author: dsamersoff Date: 2014-09-04 04:17 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c770a9cc2f86 8035419: warning from b09 for hotspot.agent.src.os.win32.windbg.sawindbg.cpp: 'JNI exception pending' Summary: added missed exceptions checks Reviewed-by: sla, sspitsyn ! agent/src/os/win32/windbg/sawindbg.cpp Changeset: 86bbebf1b7bf Author: zgu Date: 2014-09-04 14:50 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/86bbebf1b7bf 8055289: Internal Error: mallocTracker.cpp:146 fatal error: Should not use malloc for big memory block, use virtual memory instead Summary: Return NULL if memory allocation size is bigger than MAX_MALLOC_SIZE when NMT is on Reviewed-by: coleenp, gtriantafill ! src/share/vm/runtime/os.cpp ! test/TEST.groups + test/runtime/NMT/UnsafeMallocLimit.java Changeset: 7bf26f6f8d41 Author: zgu Date: 2014-09-04 14:58 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7bf26f6f8d41 Merge - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java - src/share/vm/gc_implementation/g1/heapRegionSeq.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp - test/runtime/RedefineFinalizer/RedefineFinalizer.java Changeset: 479ed4234a9d Author: coleenp Date: 2014-09-05 08:08 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/479ed4234a9d 8057570: RedefineClasses() tests fail assert(((Metadata*)obj)->is_valid()) failed: obj is valid Summary: Revert two small changes from the previous-versions cleanup with marking code cache. Reviewed-by: kvn, dcubed ! src/share/vm/code/nmethod.cpp ! src/share/vm/memory/universe.cpp Changeset: 08e071425343 Author: iklam Date: 2014-09-05 15:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/08e071425343 Merge ! src/share/vm/classfile/classLoaderData.cpp - test/compiler/intrinsics/mathexact/sanity/Verifier.java Changeset: d2f2777ac502 Author: erikj Date: 2014-08-28 11:59 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d2f2777ac502 8056053: Disable HOTSPOT_BUILD_JOBS when building with configure Reviewed-by: dholmes, ihse, dcubed ! make/Makefile ! make/aix/Makefile ! make/aix/makefiles/buildtree.make ! make/aix/makefiles/top.make ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/top.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/top.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/top.make Changeset: aff33974bb53 Author: coleenp Date: 2014-09-08 11:14 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/aff33974bb53 8057696: java -version triggers assertion for slowdebug zero builds Summary: The change as introduced with JDK-8003426 removed some zero code in cppInterpreter_zero.cpp which called generate_normal_entry() in that same file with a value of synchronized == false unconditionally. However, since the new code calls generate_normal_entry() with either true or false, the assertion in this method is no longer valid. Reviewed-by: coleenp Contributed-by: sgehwolf at redhat.com ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: afb7b10984d1 Author: igerasim Date: 2014-09-08 23:49 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/afb7b10984d1 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build Reviewed-by: dholmes, mseledtsov ! test/runtime/SharedArchiveFile/ArchiveDoesNotExist.java Changeset: 59c55db51def Author: gtriantafill Date: 2014-09-09 09:48 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/59c55db51def 8054836: [TESTBUG] Test is needed to verify correctness of malloc tracking Reviewed-by: ctornqvi, lfoltan ! test/TEST.groups + test/runtime/NMT/MallocTrackingVerify.java Changeset: f9e9ec181abb Author: minqi Date: 2014-09-08 22:48 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f9e9ec181abb 8056930: Output host info under some condition for core dump Summary: Output host name after java crashed for debug version. Reviewed-by: dholmes, ccheung Contributed-by: yumin.qi at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp Changeset: eec8e5895109 Author: minqi Date: 2014-09-09 18:56 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/eec8e5895109 Merge Changeset: f377b599ecd4 Author: brutisso Date: 2014-09-08 10:41 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f377b599ecd4 8025564: gc/memory/UniThread/Linear1 times out during heap verification Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3bb7a6358d46 Author: brutisso Date: 2014-09-09 14:27 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3bb7a6358d46 8057910: G1: BOT verification should not pass top Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp Changeset: 2240a4f04610 Author: stefank Date: 2014-09-09 13:55 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2240a4f04610 8057918: Update out-dated ignore tags in GC jtreg tests Reviewed-by: ehelin, tschatzl ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/gc/parallelScavenge/TestDynShrinkHeap.java Changeset: 6e19ec5814fd Author: mgerdin Date: 2014-09-08 17:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6e19ec5814fd 8057722: G1: Code root hashtable updated incorrectly when evacuation failed Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp Changeset: 5781de4ee90c Author: jmasa Date: 2014-09-10 23:14 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5781de4ee90c Merge - test/runtime/RedefineFinalizer/RedefineFinalizer.java Changeset: 51e474c55d20 Author: shade Date: 2014-09-04 13:11 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/51e474c55d20 8050147: StoreLoad barrier interferes with stack usages Reviewed-by: jrose, kvn, drchase ! src/cpu/x86/vm/assembler_x86.hpp ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/os.hpp Changeset: d3e712a41646 Author: kvn Date: 2014-09-04 23:49 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d3e712a41646 8057643: Unable to build --with-debug-level=optimized on OSX Summary: Added missing Hotspot make targets for 'optimized' build. Reviewed-by: iveresov ! make/Makefile ! make/bsd/makefiles/universal.gmk Changeset: 0da099111ea0 Author: zmajo Date: 2014-09-05 16:07 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0da099111ea0 8053886: assert(false) failed: Should not allocate with exception pending Summary: Failure caused by allocating method counters. Changed the way counters are allocated (use get_method_counters() instead of build_method_counters()) Reviewed-by: kvn, thartmann, anoll ! src/share/vm/runtime/sweeper.cpp Changeset: 63934ec778a2 Author: iveresov Date: 2014-09-05 11:23 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/63934ec778a2 8056124: Hotspot should use PICL interface to get cacheline size on SPARC Summary: Using libpicl to get L1 data and L2 cache line sizes Reviewed-by: kvn, roland, morris ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: 9ac4db006cd5 Author: iveresov Date: 2014-09-05 14:39 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9ac4db006cd5 8056154: JVM crash with EXCEPTION_ACCESS_VIOLATION when there are many threads running Summary: Don't make compiled MH intrinsics not entrant when redefining classes Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.hpp Changeset: 712420bcab47 Author: iveresov Date: 2014-09-08 11:45 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/712420bcab47 8057750: CTW should not make MH intrinsics not entrant Summary: Do not make MH intrinsics not entrant in CTW Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp Changeset: 6a1872937ea7 Author: simonis Date: 2014-09-08 16:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6a1872937ea7 8057780: Fix ppc build after "8050147: StoreLoad barrier interferes with stack usages Reviewed-by: kvn, shade ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp ! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Changeset: 7dace1c50e00 Author: adlertz Date: 2014-09-09 16:14 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7dace1c50e00 Merge - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp Changeset: d8ecd90aa61c Author: roland Date: 2014-09-09 15:47 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d8ecd90aa61c 8057758: Tests run TypeProfileLevel=222 crash with guarantee(0) failed: must find derived/base pair Summary: Use TypeAryPtr::INT type with offset 0 in inline_multiplyToLen(). Reviewed-by: kvn, iveresov ! src/share/vm/opto/library_call.cpp Changeset: daa5ae1d95c4 Author: iveresov Date: 2014-09-10 19:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/daa5ae1d95c4 8058092: Test vm/mlvm/meth/stress/compiler/deoptimize. Assert in src/share/vm/classfile/systemDictionary.cpp: MH intrinsic invariant Summary: Throw exception if unable to compile an MH intrinsic Reviewed-by: kvn ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/arguments.hpp Changeset: a39c9249f4be Author: iveresov Date: 2014-09-11 00:04 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a39c9249f4be 8058184: Move _highest_comp_level and _highest_osr_comp_level from MethodData to MethodCounters Summary: Tiered policy requires highest compilation levels always available Reviewed-by: kvn, vlivanov ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodCounters.cpp ! src/share/vm/oops/methodCounters.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: 60dc381b2fbb Author: neliasso Date: 2014-09-10 13:27 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/60dc381b2fbb 8054889: Compiler team's implementation task Summary: Adding three new diagnostic commands for compiler Reviewed-by: anoll, kvn, drchase ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + test/serviceability/dcmd/CodeCacheTest.java + test/serviceability/dcmd/CodelistTest.java + test/serviceability/dcmd/CompilerQueueTest.java + test/serviceability/dcmd/MethodIdentifierParser.java Changeset: 006d52c53b6b Author: neliasso Date: 2014-09-11 08:01 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/006d52c53b6b Merge Changeset: 019dba14fb53 Author: adlertz Date: 2014-09-12 09:17 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/019dba14fb53 Merge ! make/Makefile ! src/share/vm/runtime/os.hpp Changeset: 0825d4f74ef8 Author: amurillo Date: 2014-09-12 04:22 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0825d4f74ef8 Merge - test/runtime/RedefineFinalizer/RedefineFinalizer.java Changeset: af46576a8d7c Author: lana Date: 2014-09-18 13:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/af46576a8d7c Merge - test/runtime/RedefineFinalizer/RedefineFinalizer.java Changeset: 0ac594bd05c1 Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0ac594bd05c1 Added tag jdk9-b32 for changeset af46576a8d7c ! .hgtags Changeset: 2ade0284497b Author: dholmes Date: 2014-09-10 00:44 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2ade0284497b 8056183: os::is_MP() always reports true when NMT is enabled Reviewed-by: shade, coleenp, bdelsart ! src/share/vm/runtime/os.hpp Changeset: ebc96d6c7074 Author: ctornqvi Date: 2014-09-10 07:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ebc96d6c7074 8055719: Clean out support for old VC versions from ProjectCreator Summary: Clean out support for old VC versions from ProjectCreator Reviewed-by: sla, allwin ! make/windows/makefiles/projectcreator.make - src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/ProjectCreator/WinGammaPlatformVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC8.java - src/share/tools/ProjectCreator/WinGammaPlatformVC9.java Changeset: 396253716f03 Author: igerasim Date: 2014-09-10 09:52 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/396253716f03 8057744: (process) Synchronize exiting of threads and process [win] Reviewed-by: dholmes, dcubed, sla ! src/os/aix/vm/os_aix.inline.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp Changeset: 03835eaaab2d Author: dcubed Date: 2014-09-10 11:48 -0600 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/03835eaaab2d 8057107: cleanup indent white space issues prior to Contended Locking reorder and cache line bucket Reviewed-by: fparain, sspitsyn, coleenp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0420e825bb3c Author: dcubed Date: 2014-09-10 11:52 -0600 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0420e825bb3c 8057109: manual cleanup of white space issues prior to Contended Locking reorder and cache line bucket Reviewed-by: fparain, sspitsyn, coleenp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0990a645d215 Author: dcubed Date: 2014-09-10 17:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0990a645d215 Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: f679e6236dad Author: dsamersoff Date: 2014-09-11 03:13 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f679e6236dad 8054174: minor buglet in computation of end of pc descs in libjvm_db.c Summary: fixed scopes_pcs_end calculation Reviewed-by: sspitsyn, sla Contributed-by: Tom Rodriguez ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/libjvm_db.c ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 9fee52d12618 Author: coleenp Date: 2014-09-11 10:46 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9fee52d12618 8055145: [TESTBUG] runtime/7158988/FieldMonitor.java fails with VMDisconnectedException Summary: Exclude this test on JPRT and make it trivially pass if it gets a disconnected exception (which seems rare) Reviewed-by: gtriantafill, sspitsyn, ctornqvi ! test/TEST.groups ! test/runtime/7158988/FieldMonitor.java Changeset: e7748e052f65 Author: ctornqvi Date: 2014-09-11 17:54 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e7748e052f65 8022865: [TESTBUG] Compressed Oops testing needs to be revised Summary: Rewrote compressed oops tests Reviewed-by: kvn, coleenp, mseledtsov ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp + test/runtime/CompressedOops/CompressedClassSpaceSize.java + test/runtime/CompressedOops/ObjectAlignment.java + test/runtime/CompressedOops/UseCompressedOops.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java Changeset: f4c930de9991 Author: iklam Date: 2014-09-12 14:05 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f4c930de9991 Merge ! src/share/vm/runtime/os.hpp Changeset: aad2fc28a698 Author: gtriantafill Date: 2014-09-15 14:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/aad2fc28a698 8058504: [TESTBUG] Temporarily disable failing test runtime/NMT/MallocTrackingVerify.java Reviewed-by: ctornqvi, hseigel ! test/runtime/NMT/MallocTrackingVerify.java Changeset: 6bf471234b2f Author: ihse Date: 2014-09-16 12:13 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6bf471234b2f 8056999: Make hotspot builds less verbose on default log level Reviewed-by: dholmes, erikj ! make/aix/makefiles/adlc.make ! make/aix/makefiles/buildtree.make ! make/aix/makefiles/defs.make ! make/aix/makefiles/jsig.make ! make/aix/makefiles/jvmti.make ! make/aix/makefiles/rules.make ! make/aix/makefiles/sa.make ! make/aix/makefiles/saproc.make ! make/aix/makefiles/trace.make ! make/aix/makefiles/vm.make ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmti.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/trace.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/dtrace.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/trace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/trace.make ! make/solaris/makefiles/vm.make Changeset: 2b1f46ac5d49 Author: tonyp Date: 2014-09-10 11:55 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2b1f46ac5d49 8057799: Unnecessary NULL check in G1KeepAliveClosure Reviewed-by: tschatzl, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 32b18c8f19fa Author: mgerdin Date: 2014-08-26 11:53 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/32b18c8f19fa 8056039: Hotspot does not compile with clang 3.4 on Linux Reviewed-by: brutisso, sla ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Changeset: 452533d0addf Author: jwilhelm Date: 2014-09-11 14:21 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/452533d0addf 8041946: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap Summary: New test added Reviewed-by: jwilhelm, tschatzl Contributed-by: andrey.x.zakharov at oracle.com + test/gc/g1/TestShrinkDefragmentedHeap.java Changeset: 306a3f87256e Author: jwilhelm Date: 2014-09-11 14:21 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/306a3f87256e 8056237: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM Summary: Added respect for available memory. Renamed function names Reviewed-by: jwilhelm, tschatzl Contributed-by: andrey.x.zakharov at oracle.com ! test/gc/g1/TestHumongousShrinkHeap.java Changeset: 13c5569c0fc4 Author: tonyp Date: 2014-09-15 12:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/13c5569c0fc4 8057768: Make heap region region type in G1 HeapRegion explicit Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1HotCardCache.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp + src/share/vm/gc_implementation/g1/heapRegionType.cpp + src/share/vm/gc_implementation/g1/heapRegionType.hpp Changeset: cde40424bcd4 Author: ehelin Date: 2014-09-15 10:57 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cde40424bcd4 8049536: os::commit_memory on Solaris uses aligment_hint as page size Reviewed-by: stefank, tschatzl ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp + test/runtime/memory/LargePages/TestLargePageSizeInBytes.java Changeset: 3c820b8715c4 Author: jwilhelm Date: 2014-09-15 15:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3c820b8715c4 Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 510dbe16e832 Author: jwilhelm Date: 2014-09-15 13:32 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/510dbe16e832 Merge ! src/os/solaris/vm/os_solaris.cpp Changeset: b326a3e8dcab Author: ehelin Date: 2014-06-24 15:50 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b326a3e8dcab 8049864: TestParallelHeapSizeFlags fails with unexpected heap size Reviewed-by: sjohanss, jmasa ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! test/gc/arguments/TestParallelHeapSizeFlags.java Changeset: 9a2dcda0e222 Author: tschatzl Date: 2014-09-16 10:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9a2dcda0e222 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set Summary: Remove -XX:-G1DeferredRSUpdate functionality as it is racy. During evacuation failure handling, threads where evacuation failure handling occurred may try to add remembered sets to regions which remembered sets are currently being scanned. The iterator to handle the remembered set scan does not support addition of entries during scan and so may skip valid references. Reviewed-by: iveresov, brutisso, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp - test/gc/g1/TestDeferredRSUpdate.java Changeset: b97bb4bc8d21 Author: stefank Date: 2014-09-16 10:13 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b97bb4bc8d21 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr Reviewed-by: mgerdin, tschatzl, brutisso - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java ! test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java ! test/gc/class_unloading/TestG1ClassUnloadingHWM.java Changeset: 52e69512acf2 Author: stefank Date: 2014-09-16 09:31 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/52e69512acf2 Merge - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java Changeset: 44ede98c4920 Author: jwilhelm Date: 2014-09-18 19:41 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/44ede98c4920 Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp - src/share/tools/ProjectCreator/FileTreeCreatorVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC8.java - src/share/tools/ProjectCreator/WinGammaPlatformVC9.java ! src/share/vm/runtime/os.hpp Changeset: 087443edb74a Author: thartmann Date: 2014-09-15 08:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/087443edb74a 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods Summary: Removed 'InvalidOSREntryBci' and checking nmethod::_state instead to determine if an osr method is non-entrant. Reviewed-by: kvn, vlivanov, drchase ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9b8312ce5146 Author: anoll Date: 2014-09-16 14:39 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9b8312ce5146 8058452: ciInstanceKlass::non_static_fields() can be removed Summary: ciInstanceKlass::non_static_fields() and all associated data structures can be removed since they are unused. Reviewed-by: kvn, thartmann ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp Changeset: 3a59d786378b Author: iignatyev Date: 2014-09-16 21:29 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3a59d786378b 8057165: [TESTBUG] Need a test to cover JDK-8054883 Reviewed-by: kvn, iveresov, iignatyev Contributed-by: Boris Molodenkov + test/compiler/osr/TestRangeCheck.java Changeset: 4e54c93fa1b3 Author: adlertz Date: 2014-09-18 19:30 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4e54c93fa1b3 Merge Changeset: ca41b6bd9b42 Author: adlertz Date: 2014-09-18 18:40 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ca41b6bd9b42 Merge ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4ac471db103d Author: amurillo Date: 2014-09-19 01:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4ac471db103d Merge - src/share/tools/ProjectCreator/FileTreeCreatorVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC8.java - src/share/tools/ProjectCreator/WinGammaPlatformVC9.java - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java - test/gc/g1/TestDeferredRSUpdate.java Changeset: 9b3f5e4f3372 Author: lana Date: 2014-09-25 16:21 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9b3f5e4f3372 Merge - src/share/tools/ProjectCreator/FileTreeCreatorVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC8.java - src/share/tools/ProjectCreator/WinGammaPlatformVC9.java - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java - test/gc/g1/TestDeferredRSUpdate.java Changeset: 3b529384df69 Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3b529384df69 Added tag jdk9-b33 for changeset 9b3f5e4f3372 ! .hgtags Changeset: 76d7ac44841e Author: sla Date: 2014-09-23 12:17 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/76d7ac44841e 8058448: Disable JPRT submissions from the hotspot repo Reviewed-by: kvn - make/jprt.properties Changeset: 39231c6e51fe Author: thartmann Date: 2014-09-17 08:00 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/39231c6e51fe 8015774: Add support for multiple code heaps Summary: Support for segmentation of the code cache. Separate code heaps are created and used to store code of different types. Reviewed-by: kvn, iveresov, roland, anoll, egahlin, sla ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! make/solaris/makefiles/mapfile-vers-COMPILER1 ! make/solaris/makefiles/mapfile-vers-COMPILER2 ! make/solaris/makefiles/mapfile-vers-TIERED ! src/cpu/ppc/vm/c2_globals_ppc.hpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/jhelper.d ! src/os/bsd/dtrace/libjvm_db.c ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/tracetypes.xml + test/compiler/codecache/CheckSegmentedCodeCache.java Changeset: cb79004b9ac0 Author: thartmann Date: 2014-09-17 06:05 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cb79004b9ac0 Merge Changeset: e69e34d8c1a6 Author: neliasso Date: 2014-09-18 08:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e69e34d8c1a6 8058583: Remove CompilationRepeat Summary: Remove product flag -XX:CompilationRepeat Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/compiler/compileBroker.cpp Changeset: 75e7ad74fba8 Author: iveresov Date: 2014-09-17 21:15 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/75e7ad74fba8 8058564: Tiered compilation performance drop in PIT Summary: Ensure MethodCounters are created before method is enqueued for compilation Reviewed-by: kvn, drchase, jiangli ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 4f215d30ca7b Author: iveresov Date: 2014-09-18 08:32 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4f215d30ca7b Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 16bfa5fdbfc0 Author: roland Date: 2014-09-17 14:56 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/16bfa5fdbfc0 8058636: test case for 8057758 Summary: missing test case in push for 8057758 Reviewed-by: kvn, iveresov + test/compiler/intrinsics/multiplytolen/TestMultiplyToLenReturnProfile.java Changeset: 15f4d29d9956 Author: roland Date: 2014-09-18 09:16 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/15f4d29d9956 Merge Changeset: 04e52cc3d973 Author: zmajo Date: 2014-09-18 12:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/04e52cc3d973 8050407: Add jtreg compiler tests to Hotspot JPRT jobs Summary: Select useful jtreg test. Group tests into four sets (3 sets with open tests, 1 set with closed tests) so that execution time of each set is < 10 min on solaris_sparcv9 (slowest platform). Reviewed-by: kvn, anoll, roland ! make/jprt.properties ! test/TEST.groups Changeset: ca010d2665ca Author: morris Date: 2014-09-18 11:46 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ca010d2665ca 8050022: linux-sparcv9: assert(SharedSkipVerify || obj->is_oop()) failed: sanity check Summary: Provide promoted stack slots for floating-point registers in the SPARC c_calling_convention. Reviewed-by: kvn, jrose, drchase ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad Changeset: 2f606e0c4866 Author: goetz Date: 2014-09-18 09:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2f606e0c4866 8058716: Add include missing in 8015774 Reviewed-by: kvn ! src/share/vm/code/codeCache.cpp Changeset: 97e9fba4c8c8 Author: neliasso Date: 2014-09-19 10:31 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/97e9fba4c8c8 8058479: serviceability/dcmd/CodeCacheTest.java fails Summary: Don't parse really large hex values into a long Reviewed-by: kvn, anoll ! test/serviceability/dcmd/CodeCacheTest.java Changeset: e99bef33c53d Author: neliasso Date: 2014-09-15 17:12 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e99bef33c53d 8058461: serviceability/dcmd/CodelistTest.java and serviceability/dcmd/CompilerQueueTest.java SIGSEGV Summary: Print only alive nmethods and add lock to print compile queue Reviewed-by: kvn, anoll ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 3741294061b8 Author: neliasso Date: 2014-09-19 10:24 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3741294061b8 Merge Changeset: f111958ca117 Author: adlertz Date: 2014-09-19 17:14 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f111958ca117 Merge ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/libjvm_db.c ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c - src/share/tools/ProjectCreator/FileTreeCreatorVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC8.java - src/share/tools/ProjectCreator/WinGammaPlatformVC9.java ! src/share/vm/code/codeCache.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/heap.cpp ! test/TEST.groups - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java - test/gc/g1/TestDeferredRSUpdate.java Changeset: a4160fc27dd6 Author: thartmann Date: 2014-09-21 16:13 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a4160fc27dd6 8058712: [TESTBUG] serviceability/dcmd/CodeCacheTest.java fails with java.lang.Exception Summary: The test is changed to check the output according to the number of available code segments. Reviewed-by: kvn ! test/serviceability/dcmd/CodeCacheTest.java Changeset: d7990731ecad Author: drchase Date: 2014-09-22 14:19 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d7990731ecad 8058827: XCode 6.0 (Clang) warning "operator new' should not return a null pointer unless..." Summary: Rewrote the null pointer in a way that is not recognized by the compiler (the code is never executed). Reviewed-by: kvn ! src/share/vm/memory/allocation.cpp Changeset: 4d52ce03809d Author: sla Date: 2014-09-23 14:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4d52ce03809d Merge - make/jprt.properties Changeset: 1a2509685e1a Author: ctornqvi Date: 2014-09-17 06:55 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1a2509685e1a 8058369: [TESTBUG] runtime/CompressedOops/UseCompressedOops.java Exception java.lang.RuntimeException: 'Zero based' missing from stdout/stderr Summary: Solaris and OSX places the heap in unpredictable places, some of the test must be excluded on these platforms Reviewed-by: hseigel, coleenp ! test/runtime/CompressedOops/UseCompressedOops.java Changeset: 4cd9316c641e Author: hseigel Date: 2014-09-19 08:19 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4cd9316c641e 8057845: ClassVerifier::verify_exception_handler_targets reconstructs the ExceptionTable in a loop Summary: Construct the ExceptionTable only once, before the loop Reviewed-by: acorn, jiangli, coleenp, lfoltan ! src/share/vm/classfile/verifier.cpp Changeset: 315c87f8751d Author: iklam Date: 2014-09-19 13:47 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/315c87f8751d Merge - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java - test/gc/g1/TestDeferredRSUpdate.java Changeset: 43902075180a Author: coleenp Date: 2014-09-19 21:13 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/43902075180a 8058843: TEST.groups has runtime/runtime/7158988/FieldMonitor.java Summary: remove a runtime Reviewed-by: ctornqvi, sspitsyn, kvn ! test/TEST.groups Changeset: ec1600663db0 Author: sla Date: 2014-09-23 14:17 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ec1600663db0 Merge - make/jprt.properties Changeset: a7666e951eb7 Author: iklam Date: 2014-09-24 09:48 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a7666e951eb7 Merge ! test/TEST.groups Changeset: bf402e85d046 Author: iveresov Date: 2014-09-23 15:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bf402e85d046 8058744: Crash in C1 OSRed method w/ Unsafe usage Summary: Fix UnsafeRawOp optimizations Reviewed-by: kvn, drchase, vlivanov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 6aada1367ea2 Author: iveresov Date: 2014-09-23 17:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6aada1367ea2 8059002: 8058744 needs a test case Summary: Added a test case the UnsafeRawOp intrinsics Reviewed-by: kvn + test/compiler/unsafe/UnsafeRaw.java Changeset: 86183a940db4 Author: simonis Date: 2014-09-24 12:19 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/86183a940db4 8058345: Refactor native stack printing from vmError.cpp to debug.cpp to make it available in gdb as well Summary: Also fix stack trace on x86 to enable walking of runtime stubs and native wrappers Reviewed-by: kvn ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 1095d1f4ad80 Author: adlertz Date: 2014-09-25 23:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1095d1f4ad80 Merge Changeset: 74e33aa4681a Author: jwilhelm Date: 2014-09-18 18:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/74e33aa4681a Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/runtime/os.hpp - test/gc/class_unloading/AllocateBeyondMetaspaceSize.java - test/gc/g1/TestDeferredRSUpdate.java Changeset: 8270a0a2ba89 Author: jwilhelm Date: 2014-09-16 16:02 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8270a0a2ba89 8055006: Store original value of Min/MaxHeapFreeRatio Summary: Store the value set by the user and some makefile changes required to change the flags. Reviewed-by: sla, mchung, bchristi, jmasa, dholmes, erikj ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 916324700573 Author: jwilhelm Date: 2014-08-22 13:24 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/916324700573 8055744: 8u-dev nightly solaris builds failed on 08/20 Summary: Fixed makefiles on solaris to allow build with extra symbols. Reviewed-by: dcubed, erikj ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make Changeset: fe15f8267f87 Author: jwilhelm Date: 2014-09-05 00:28 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fe15f8267f87 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile Summary: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile Reviewed-by: erikj, dholmes ! make/solaris/Makefile Changeset: c919a19a9d9c Author: jprovino Date: 2014-09-19 09:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c919a19a9d9c 8058534: Remove HeapRegion::_orig_end Summary: Also reviewed by kim.barrett at oracle.com Reviewed-by: tonyp, brutisso, tschatzl ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 980ffcca3740 Author: jwilhelm Date: 2014-09-19 11:51 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/980ffcca3740 Merge ! src/os/solaris/vm/os_solaris.cpp Changeset: bee5befdd4f9 Author: mlarsson Date: 2014-09-18 12:45 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bee5befdd4f9 8055091: CollectedHeap::_reserved usage should be cleaned up Summary: Added an initialization function for _reserved. Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp Changeset: 7894458add89 Author: mlarsson Date: 2014-09-18 11:27 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7894458add89 8053998: Hot card cache flush chunk size too coarse grained Summary: Changed the chunk size to a smaller fixed number. Reviewed-by: tschatzl, mgerdin ! src/share/vm/gc_implementation/g1/g1HotCardCache.cpp ! src/share/vm/gc_implementation/g1/g1HotCardCache.hpp Changeset: 9b65f43493d8 Author: mlarsson Date: 2014-09-18 11:04 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9b65f43493d8 8035729: Code using assert(is_oop_or_null) needs better error messages Summary: Modified error messages to include the oops Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 4e985654db5b Author: brutisso Date: 2014-09-19 12:11 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4e985654db5b Merge Changeset: d71c45ffed4c Author: jwilhelm Date: 2014-09-22 16:22 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d71c45ffed4c Merge Changeset: 812725420769 Author: sla Date: 2014-09-04 11:21 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/812725420769 8057535: add a thread extension class Reviewed-by: mgerdin, bdelsart, jcoomes ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp + src/share/vm/runtime/thread_ext.cpp + src/share/vm/runtime/thread_ext.hpp ! src/share/vm/services/management.cpp Changeset: c04d77177920 Author: jcoomes Date: 2014-09-04 09:37 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c04d77177920 8054970: gc src file exclusion should exclude alternative sources Reviewed-by: ehelin, stefank ! make/excludeSrc.make Changeset: 0df1606be959 Author: jcoomes Date: 2014-09-04 16:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0df1606be959 8057531: refactor gc argument processing code slightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 5e081c4e4fce Author: sjohanss Date: 2014-09-05 09:49 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5e081c4e4fce 8057536: Refactor G1 to allow context specific allocations Summary: Splitting out a g1 allocator class to simply specialized allocators which can associate each allocation with a given context. Reviewed-by: mgerdin, brutisso + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1Allocator.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp + src/share/vm/gc_implementation/g1/g1AllocationContext.hpp + src/share/vm/gc_implementation/g1/g1Allocator.cpp + src/share/vm/gc_implementation/g1/g1Allocator.hpp + src/share/vm/gc_implementation/g1/g1Allocator_ext.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 5c7b72d062bd Author: jcoomes Date: 2014-09-05 12:36 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5c7b72d062bd 8057623: add an extension class for argument handling Reviewed-by: brutisso, mgerdin, tschatzl ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp - src/share/vm/runtime/arguments_ext.cpp + src/share/vm/runtime/arguments_ext.hpp Changeset: 20b6ad26387a Author: sjohanss Date: 2014-09-09 00:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/20b6ad26387a 8057658: Enable G1 FullGC extensions Summary: Refactored the G1 FullGC code to enable it to be extended. Reviewed-by: mgerdin, brutisso ! src/share/vm/gc_implementation/g1/g1Allocator.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp + src/share/vm/gc_implementation/g1/g1MarkSweep_ext.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionManager.cpp ! src/share/vm/memory/space.hpp Changeset: 6d9b5aa357aa Author: sjohanss Date: 2014-09-09 04:48 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6d9b5aa357aa 8057710: Refactor G1 heap region default sizes Summary: Refactored the defines to instead be static const in a HeapRegionBounds class. Reviewed-by: mgerdin, tschatzl ! src/share/vm/gc_implementation/g1/heapRegion.cpp + src/share/vm/gc_implementation/g1/heapRegionBounds.hpp + src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp Changeset: 2f481af73ec4 Author: jcoomes Date: 2014-09-10 13:01 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2f481af73ec4 8057818: collect allocation context statistics at gc pauses Reviewed-by: mikael, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1AllocationContext.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp Changeset: 09d9871af47b Author: jcoomes Date: 2014-09-10 13:01 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/09d9871af47b 8057824: methods to copy allocation context statistics Reviewed-by: mikael, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1CollectedHeap_ext.cpp ! src/share/vm/gc_interface/collectedHeap.hpp Changeset: e5c84e2c461a Author: jcoomes Date: 2014-09-10 16:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e5c84e2c461a 8057827: notify an obj when allocation context stats are available Reviewed-by: mikael, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1AllocationContext.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/memory/universe.inline.hpp ! src/share/vm/runtime/serviceThread.cpp + src/share/vm/services/allocationContextService.hpp Changeset: a513d9d3cd85 Author: sjohanss Date: 2014-09-08 15:24 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a513d9d3cd85 8057752: WhiteBox extension support for testing Summary: Refactored parts of whitebox.cpp to enable registration of whitebox methods defined outside this file. Reviewed-by: mikael, ctornqvi, jmasa ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp + src/share/vm/prims/whitebox_ext.cpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 545e90b97200 Author: jcoomes Date: 2014-09-11 17:13 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/545e90b97200 8058235: identify GCs initiated to update allocation context stats Reviewed-by: mikael, sjohanss ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: f29fc48b201f Author: tonyp Date: 2014-09-23 11:43 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f29fc48b201f 8058495: G1: normalize names for isHumongous() and friends Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1Allocator.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionManager.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionType.cpp ! src/share/vm/gc_implementation/g1/heapRegionType.hpp ! src/share/vm/prims/whitebox.cpp Changeset: 4ebca3691ded Author: jprovino Date: 2014-09-23 12:34 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4ebca3691ded 8027450: Improve time reporting in G1 remark Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 0877f69d900b Author: stefank Date: 2014-09-23 12:52 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0877f69d900b Merge ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 74305fe8f509 Author: sla Date: 2014-09-23 14:18 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/74305fe8f509 Merge - make/jprt.properties Changeset: cedaeee5e645 Author: brutisso Date: 2014-09-24 11:00 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cedaeee5e645 8036116: Fix thread-id types in G1 remembered set implementations Reviewed-by: stefank, jprovino, brutisso Contributed-by: sangheon.kim at oracle.com ! src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: 5051bb01fa2b Author: mgerdin Date: 2014-09-25 10:01 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5051bb01fa2b 8055141: Catch linker errors earlier in the JVM build by not allowing unresolved externals Reviewed-by: erikj, ehelin, dholmes ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: a2324f55f474 Author: jwilhelm Date: 2014-09-22 16:22 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a2324f55f474 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 4786d13c5d7d Author: jwilhelm Date: 2014-09-26 06:07 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4786d13c5d7d Merge - src/share/vm/runtime/arguments_ext.cpp Changeset: c5ad82e4b5a7 Author: amurillo Date: 2014-09-26 01:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c5ad82e4b5a7 Merge - make/jprt.properties - src/share/vm/runtime/arguments_ext.cpp Changeset: 821164b0131a Author: lana Date: 2014-10-03 12:11 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/821164b0131a Merge - make/jprt.properties - src/share/vm/runtime/arguments_ext.cpp Changeset: 413cdfd8d0fe Author: katleman Date: 2014-10-09 11:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/413cdfd8d0fe Added tag jdk9-b34 for changeset 821164b0131a ! .hgtags Changeset: 2a8ac31cdef9 Author: mcimadamore Date: 2014-10-15 10:59 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2a8ac31cdef9 merge with jdk9-b34 - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java - make/jprt.properties - src/share/tools/ProjectCreator/FileTreeCreatorVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC7.java - src/share/tools/ProjectCreator/WinGammaPlatformVC8.java - src/share/tools/ProjectCreator/WinGammaPlatformVC9.java ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.cpp - src/share/vm/gc_implementation/g1/heapRegionSeq.hpp - src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp - src/share/vm/runtime/arguments_ext.cpp - src/share/vm/services/memPtr.cpp - src/share/vm/services/memPtr.hpp - src/share/vm/services/memPtrArray.hpp - src/share/vm/services/memRecorder.cpp - src/share/vm/services/memRecorder.hpp - src/share/vm/services/memSnapshot.cpp - src/share/vm/services/memSnapshot.hpp - src/share/vm/services/memTrackWorker.cpp - src/share/vm/services/memTrackWorker.hpp - test/compiler/intrinsics/mathexact/sanity/Verifier.java - test/gc/g1/TestDeferredRSUpdate.java - test/runtime/RedefineFinalizer/RedefineFinalizer.java From maurizio.cimadamore at oracle.com Wed Oct 15 13:13:19 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 Oct 2014 13:13:19 +0000 Subject: hg: valhalla/valhalla/langtools: 83 new changesets Message-ID: <201410151313.s9FDDKUk000592@aojmv0008> Changeset: 0529b1e3369b Author: ohrstrom Date: 2014-08-08 20:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0529b1e3369b 8054461: Add @file support to sjavac Summary: Add @file support to sjavac commandline. Reviewed-by: jjg, alundblad ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/options/OptionHelper.java ! src/share/classes/com/sun/tools/sjavac/options/Options.java ! test/tools/sjavac/SJavac.java Changeset: 2cfae1808440 Author: ohrstrom Date: 2014-08-08 21:26 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2cfae1808440 8054474: Add --state-dir=bar to sjavac Summary: Add --state-dir=bar to sjavac to control where sjavac stores the javac_state file. Reviewed-by: jjg, alundblad ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/comp/JavacServiceImpl.java ! src/share/classes/com/sun/tools/sjavac/options/Option.java ! src/share/classes/com/sun/tools/sjavac/options/OptionHelper.java ! src/share/classes/com/sun/tools/sjavac/options/Options.java ! src/share/classes/com/sun/tools/sjavac/server/JavacService.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServiceClient.java ! test/tools/sjavac/SJavac.java Changeset: bbacfb416096 Author: ohrstrom Date: 2014-08-09 00:56 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bbacfb416096 8054465: Add --permit-artifact=bar to sjavac Summary: Add --permit-artifact=bar to white-list files that have been written to the destination directory and that sjavac should not delete. Reviewed-by: jjg, alundblad ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/options/Option.java ! src/share/classes/com/sun/tools/sjavac/options/OptionHelper.java ! src/share/classes/com/sun/tools/sjavac/options/Options.java ! test/tools/sjavac/OptionDecoding.java ! test/tools/sjavac/SJavac.java Changeset: 13b7f52d197c Author: lana Date: 2014-08-09 21:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/13b7f52d197c Added tag jdk9-b26 for changeset bbacfb416096 ! .hgtags Changeset: 8bae77602474 Author: ksrini Date: 2014-08-11 10:16 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8bae77602474 8054044: [javadoc] javadoc tester must print out the javadoc run arguments. Reviewed-by: jjg, sogoel ! test/com/sun/javadoc/lib/JavadocTester.java Changeset: 2c72dfde538d Author: lana Date: 2014-08-11 10:05 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2c72dfde538d Merge ! .hgtags Changeset: c998c4293abc Author: lana Date: 2014-08-11 11:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c998c4293abc Merge Changeset: 64dd93efba84 Author: sogoel Date: 2014-08-12 16:41 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/64dd93efba84 8054964: Add a test for invalid package annotations Reviewed-by: jjg + test/tools/javac/annotations/neg/InvalidPackageAnno.java + test/tools/javac/annotations/neg/InvalidPackageAnno.out + test/tools/javac/annotations/neg/bar/package-info.java Changeset: 1e8664df1b9c Author: sogoel Date: 2014-08-12 17:31 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/1e8664df1b9c 8049127: Group 8b - golden files for annotations test in tools/java dir Reviewed-by: jjg ! test/tools/javac/annotations/neg/NoAnnotationMethods.java + test/tools/javac/annotations/neg/NoAnnotationMethods.out ! test/tools/javac/annotations/neg/NoClone.java + test/tools/javac/annotations/neg/NoClone.out ! test/tools/javac/annotations/neg/NoObjectMethods.java + test/tools/javac/annotations/neg/NoObjectMethods.out ! test/tools/javac/annotations/neg/ObjectMembers.java + test/tools/javac/annotations/neg/ObjectMembers.out ! test/tools/javac/annotations/neg/OverrideNo.java + test/tools/javac/annotations/neg/OverrideNo.out ! test/tools/javac/annotations/neg/Package.java + test/tools/javac/annotations/neg/Package.out ! test/tools/javac/annotations/neg/Recovery.java + test/tools/javac/annotations/neg/Recovery.out ! test/tools/javac/annotations/neg/Recovery1.java + test/tools/javac/annotations/neg/Recovery1.out ! test/tools/javac/annotations/neg/Scope.java + test/tools/javac/annotations/neg/Scope.out ! test/tools/javac/annotations/neg/Syntax1.java + test/tools/javac/annotations/neg/Syntax1.out Changeset: e6bed5e8f0f0 Author: sogoel Date: 2014-08-12 17:39 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e6bed5e8f0f0 8049129: Group 8c - golden files for annotations test in tools/java dir Reviewed-by: jjg ! test/tools/javac/annotations/neg/WrongTarget.java + test/tools/javac/annotations/neg/WrongTarget.out ! test/tools/javac/annotations/neg/WrongTarget2.java + test/tools/javac/annotations/neg/WrongTarget2.out ! test/tools/javac/annotations/neg/WrongValue.java + test/tools/javac/annotations/neg/WrongValue.out ! test/tools/javac/annotations/neg/Z10.java + test/tools/javac/annotations/neg/Z10.out ! test/tools/javac/annotations/neg/Z11.java + test/tools/javac/annotations/neg/Z11.out ! test/tools/javac/annotations/neg/Z12.java + test/tools/javac/annotations/neg/Z12.out ! test/tools/javac/annotations/neg/Z13.java + test/tools/javac/annotations/neg/Z13.out ! test/tools/javac/annotations/neg/Z14.java + test/tools/javac/annotations/neg/Z14.out ! test/tools/javac/annotations/neg/Z15.java + test/tools/javac/annotations/neg/Z15.out ! test/tools/javac/annotations/neg/Z16.java + test/tools/javac/annotations/neg/Z16.out Changeset: 01d5bf0c20eb Author: sogoel Date: 2014-08-12 17:48 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/01d5bf0c20eb 8049130: Group 8d - golden files for annotations test in tools/java dir Reviewed-by: jjg ! test/tools/javac/annotations/neg/Z1.java + test/tools/javac/annotations/neg/Z1.out ! test/tools/javac/annotations/neg/Z2.java + test/tools/javac/annotations/neg/Z2.out ! test/tools/javac/annotations/neg/Z3.java + test/tools/javac/annotations/neg/Z3.out ! test/tools/javac/annotations/neg/Z4.java + test/tools/javac/annotations/neg/Z4.out ! test/tools/javac/annotations/neg/Z5.java + test/tools/javac/annotations/neg/Z5.out ! test/tools/javac/annotations/neg/Z8.java + test/tools/javac/annotations/neg/Z8.out ! test/tools/javac/annotations/neg/Z9.java + test/tools/javac/annotations/neg/Z9.out ! test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.out ! test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.out ! test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.out Changeset: 98a99928a76b Author: alundblad Date: 2014-08-13 14:44 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/98a99928a76b 8048457: Sjavac should not use portfiles, sockets, etc if background=false 8044131: Restructure client / server protocol code Summary: Changes protocol code to use Object input/output streams. Avoids spawning server if background=false. Refactors idleness checks, pooling and port file monitoring. Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/CleanProperties.java ! src/share/classes/com/sun/tools/sjavac/CompileChunk.java ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java ! src/share/classes/com/sun/tools/sjavac/CompileProperties.java ! src/share/classes/com/sun/tools/sjavac/CopyFile.java ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Log.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/Module.java ! src/share/classes/com/sun/tools/sjavac/Package.java ! src/share/classes/com/sun/tools/sjavac/ProblemException.java ! src/share/classes/com/sun/tools/sjavac/Source.java ! src/share/classes/com/sun/tools/sjavac/Transformer.java ! src/share/classes/com/sun/tools/sjavac/Util.java + src/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/share/classes/com/sun/tools/sjavac/comp/AttrWithDeps.java ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java ! src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java - src/share/classes/com/sun/tools/sjavac/comp/JavacServiceImpl.java + src/share/classes/com/sun/tools/sjavac/comp/PooledSjavac.java ! src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/SjavacErrorHandler.java + src/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java ! src/share/classes/com/sun/tools/sjavac/options/ArgumentIterator.java ! src/share/classes/com/sun/tools/sjavac/options/Option.java ! src/share/classes/com/sun/tools/sjavac/options/OptionHelper.java ! src/share/classes/com/sun/tools/sjavac/options/Options.java ! src/share/classes/com/sun/tools/sjavac/options/SourceLocation.java ! src/share/classes/com/sun/tools/sjavac/server/CompilationResult.java - src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java - src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + src/share/classes/com/sun/tools/sjavac/server/IdleResetSjavac.java - src/share/classes/com/sun/tools/sjavac/server/JavacServer.java - src/share/classes/com/sun/tools/sjavac/server/JavacService.java - src/share/classes/com/sun/tools/sjavac/server/JavacServiceClient.java ! src/share/classes/com/sun/tools/sjavac/server/PortFile.java + src/share/classes/com/sun/tools/sjavac/server/PortFileMonitor.java + src/share/classes/com/sun/tools/sjavac/server/RequestHandler.java + src/share/classes/com/sun/tools/sjavac/server/Sjavac.java + src/share/classes/com/sun/tools/sjavac/server/SjavacServer.java ! src/share/classes/com/sun/tools/sjavac/server/SysInfo.java + src/share/classes/com/sun/tools/sjavac/server/Terminable.java + test/tools/sjavac/IdleShutdown.java + test/tools/sjavac/PooledExecution.java Changeset: 09bb56ec5fec Author: emc Date: 2014-08-13 14:25 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/09bb56ec5fec 8055054: Remove visitWildcard visitor method from erasure visitor Summary: Remove suspicious visitor method that should not be present Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: a108029dbcbf Author: jjg Date: 2014-08-13 13:20 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a108029dbcbf 8050429: Update/cleanup ToolBox Reviewed-by: vromero ! make/build.properties ! test/tools/apt/Basics/CheckAptIsRemovedTest.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java ! test/tools/javac/AnonymousSubclassTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ConstFoldTest.java ! test/tools/javac/ExtDirs/ExtDirTest.java ! test/tools/javac/IncorrectInheritance/IncorrectInheritanceTest.java ! test/tools/javac/MissingInclude/MissingIncludeTest.java ! test/tools/javac/Paths/AbsolutePathTest.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/T5090006/AssertionFailureTest.java ! test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java ! test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java ! test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java ! test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java ! test/tools/javac/T8013394/CompileErrorWithIteratorTest.java ! test/tools/javac/T8019486/WrongLNTForLambdaTest.java ! test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java ! test/tools/javac/api/ToolProvider/HelloWorldTest.java ! test/tools/javac/api/ToolProvider/ToolProviderTest1.java ! test/tools/javac/api/ToolProvider/ToolProviderTest2.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTableTest.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTypeTableTest.java ! test/tools/javac/classfiles/attributes/SourceFile/AnonymousClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/InnerClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/LocalClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/MixTest.java ! test/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java ! test/tools/javac/classfiles/attributes/SourceFile/SyntheticClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/TopLevelClassesOneFileTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedPackageTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java ! test/tools/javac/defaultMethodsVisibility/DefaultMethodsNotVisibleForSourceLessThan8Test.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/innerClassFile/InnerClassFileTest.java ! test/tools/javac/javazip/JavaZipTest.java ! test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java - test/tools/javac/lib/ToolBox.java ! test/tools/javac/links/LinksTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javac/processing/rounds/CompleteOnClosed.java ! test/tools/javac/processing/rounds/OverwriteBetweenCompilations.java ! test/tools/javac/stackmap/StackMapTest.java ! test/tools/javah/6257087/T6257087.java ! test/tools/javah/T4942232/MissingParamClassTest.java ! test/tools/javah/constMacroTest/ConstMacroTest.java ! test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java ! test/tools/javap/4866831/PublicInterfaceTest.java ! test/tools/javap/stackmap/StackmapTest.java + test/tools/lib/ToolBox.java Changeset: b6fef26b6c0b Author: aeremeev Date: 2014-08-12 13:24 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b6fef26b6c0b 8042251: Implement classfile tests for InnerClasses attribute. Reviewed-by: jjg, anazarov, shurailine + test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerClassTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerEnumTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerInterfaceTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesHierarchyTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInAnonymousClassTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerAnnotationTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTestBase.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerEnumTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerInterfaceTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInLocalClassTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesIndexTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTestBase.java + test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerAnnotationTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerEnumTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerInterfaceTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerEnumsInInnerClassTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerAnnotationTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerClassTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerEnumTest.java + test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerInterfaceTest.java + test/tools/javac/classfiles/attributes/innerclasses/NoInnerClassesTest.java + test/tools/javac/classfiles/attributes/innerclasses/README.txt + test/tools/javac/classfiles/attributes/innerclasses/TestCase.java ! test/tools/javac/classfiles/attributes/lib/TestBase.java ! test/tools/javac/classfiles/attributes/lib/TestResult.java Changeset: 525e4b838572 Author: emc Date: 2014-08-13 21:58 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/525e4b838572 Merge Changeset: 557413561cd1 Author: jjg Date: 2014-08-13 15:47 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/557413561cd1 8055076: fix test failures in classfile tests Reviewed-by: darcy ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesHierarchyTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInAnonymousClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInLocalClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesIndexTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/NoInnerClassesTest.java Changeset: a5b455614604 Author: alundblad Date: 2014-08-14 13:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a5b455614604 8054215: Use com.sun.tools.javac.util.Assert instead of 'assert' Summary: Replaced assert keyword with methods from com.sun.tools.javac.util.Assert Reviewed-by: jfranck ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/Package.java ! src/share/classes/com/sun/tools/sjavac/Util.java ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java ! src/share/classes/com/sun/tools/sjavac/server/PortFile.java Changeset: 9e8cbfac9b6b Author: alundblad Date: 2014-08-14 14:17 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9e8cbfac9b6b 8055039: Sjavac does not print compilation errors to the console Summary: Sjavac (client) now prints the result of the compilation on stdout/stderr. Reviewed-by: jfranck ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java Changeset: 383432f1719c Author: pgovereau Date: 2014-08-15 11:02 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/383432f1719c 8054556: javac should report the error for default usage as the primary error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/annotations/neg/Z3.java ! test/tools/javac/annotations/neg/Z3.out Changeset: 035b01d356ee Author: chegar Date: 2014-08-18 10:59 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/035b01d356ee Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/BuildState.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CleanProperties.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CompileChunk.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CompileProperties.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CopyFile.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Module.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Package.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/ProblemException.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Transformer.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/AttrWithDeps.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/JavacServiceImpl.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PooledSjavac.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacErrorHandler.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/ArgumentIterator.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/OptionHelper.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Options.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/SourceLocation.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilationResult.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilerPool.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/IdleResetSjavac.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacServer.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacService.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacServiceClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFile.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFileMonitor.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/RequestHandler.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/Sjavac.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SysInfo.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/Terminable.java - test/tools/javac/lib/ToolBox.java Changeset: 75e8065a3e88 Author: mcimadamore Date: 2014-08-19 12:13 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/75e8065a3e88 8055390: IntelliJ langtools project should reflect modular source tree Summary: Adjust langtools.iml to point to the new source trees Reviewed-by: jfranck ! make/intellij/langtools.iml Changeset: 4d1ea4477956 Author: ksrini Date: 2014-08-19 15:34 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4d1ea4477956 8055501: [javac] ignore test/tools/javac/Paths/AbsolutePathTest.java Reviewed-by: jjg ! test/tools/javac/Paths/AbsolutePathTest.java Changeset: 016786f79314 Author: lana Date: 2014-08-28 14:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/016786f79314 Merge ! .hgtags - src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/JavacServiceImpl.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilerPool.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilerThread.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacServer.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacService.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacServiceClient.java - test/tools/javac/lib/ToolBox.java Changeset: 407df169f50e Author: katleman Date: 2014-08-29 11:30 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/407df169f50e Added tag jdk9-b28 for changeset 016786f79314 ! .hgtags Changeset: bad77727fa11 Author: erikj Date: 2014-08-22 12:25 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bad77727fa11 8055767: Sjavac is leaking servers Reviewed-by: alundblad, jfranck ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java Changeset: 50b448c5be54 Author: jjg Date: 2014-08-22 16:28 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/50b448c5be54 8044859: javac duplicates option processing when using Compiler API Reviewed-by: mcimadamore, vromero, jlahoda ! make/build.properties ! src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java + src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/6457284/T6457284.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java ! test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java ! test/tools/javac/api/6410643/T6410643.java ! test/tools/javac/api/T6357331.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/TestJavacTask_Lock.java ! test/tools/javac/api/TestResolveError.java ! test/tools/javac/api/taskListeners/CompileEvent.java ! test/tools/javac/api/taskListeners/EventsBalancedTest.java ! test/tools/javac/failover/CheckAttributedTree.java + test/tools/javac/options/modes/AtFilesTest.java + test/tools/javac/options/modes/DocLintTest.java + test/tools/javac/options/modes/FSInfoTest.java + test/tools/javac/options/modes/InfoOptsTest.java + test/tools/javac/options/modes/NoOperandsTest.java + test/tools/javac/options/modes/OutputDirTest.java + test/tools/javac/options/modes/ProfileBootClassPathTest.java + test/tools/javac/options/modes/ProfileTargetTest.java + test/tools/javac/options/modes/SourceTargetTest.java + test/tools/javac/options/modes/StdOutTest.java + test/tools/javac/options/modes/Tester.java ! test/tools/javac/profiles/ProfileOptionTest.java ! test/tools/javac/versions/Versions.java Changeset: f2518ce1dabc Author: mcimadamore Date: 2014-08-26 12:45 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/f2518ce1dabc 8056055: IntelliJ source paths broken after modularization of langtools Summary: Add 'share/classes' prefix to all src roots Reviewed-by: jfranck ! make/intellij/langtools.iml Changeset: 8e638f046bf0 Author: jlahoda Date: 2014-08-27 07:44 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8e638f046bf0 8056061: Mark implementations of public interfaces with an annotation Summary: Adding @DefinedBy annotation to mark methods that implement public API methods; annotating the methods; adding a coding rules analyzer to enforce all such methods are annotated. Reviewed-by: jjg, mcimadamore, jfranck Contributed-by: jan.lahoda at oracle.com, jonathan.gibbons at oracle.com + make/test/crules/DefinedByAnalyzer/Test.java + make/test/crules/DefinedByAnalyzer/Test.out ! make/tools/crules/AbstractCodingRulesAnalyzer.java ! make/tools/crules/CodingRulesAnalyzerPlugin.java + make/tools/crules/DefinedByAnalyzer.java ! make/tools/crules/resources/crules.properties ! src/jdk.compiler/share/classes/com/sun/tools/doclint/Checker.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/MultiTaskListener.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.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/util/BaseFileManager.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/DefinedBy.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Position.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTool.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/LLNI.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/TypeSignature.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/Util.java ! src/jdk.compiler/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/api/JavadocTaskImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/api/JavadocTool.java Changeset: a75064469e3f Author: mcimadamore Date: 2014-08-27 11:41 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a75064469e3f 8056075: Add support for dumping inference dependency graphs Summary: Add option '-XDdumpInferenceGraphTo=' to dump inference internal dependency graphs Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java Changeset: 00d021d01485 Author: ksrini Date: 2014-08-27 06:25 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/00d021d01485 8038732: [javadoc] NetBeans IDE target does not build doclets Reviewed-by: jjg, jlahoda ! make/build.properties ! make/build.xml ! make/tools/anttasks/GenStubsTask.java ! make/tools/anttasks/SelectToolTask.java Changeset: bc4d5d9f30f0 Author: ksrini Date: 2014-08-26 08:12 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bc4d5d9f30f0 8054925: [javadoc] refactor the Doclet start method. Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java Changeset: 506a8e26a53e Author: ksrini Date: 2014-08-27 06:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/506a8e26a53e 8050031: [javadoc] class-use pages have duplicates and missing entries Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Utils.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testOrdering/TestOrdering.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java + test/com/sun/javadoc/testUseOption/unique/C1.java + test/com/sun/javadoc/testUseOption/unique/UseMe.java Changeset: 452dd2988607 Author: alundblad Date: 2014-08-28 17:38 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/452dd2988607 8054500: Refactor sjavac Main class into ClientMain and ServerMain Summary: Restructured Main into ClientMain and ServerMain Reviewed-by: jfranck ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Main.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/ClientMain.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/ServerMain.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java ! test/tools/sjavac/ExclPattern.java ! test/tools/sjavac/IgnoreSymbolFile.java ! test/tools/sjavac/OptionDecoding.java ! test/tools/sjavac/SJavac.java Changeset: 23a08a5e36d6 Author: darcy Date: 2014-08-28 11:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/23a08a5e36d6 8056283: @ignore tools/javac/defaultMethods/Assertions.java until JDK-8047675 is fixed Reviewed-by: ksrini ! test/tools/javac/defaultMethods/Assertions.java Changeset: 9fbec2de1d14 Author: sogoel Date: 2014-08-28 23:42 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9fbec2de1d14 8049126: golden files for annotations test in tools/java dir Reviewed-by: jjg ! test/tools/javac/annotations/neg/AnnComma.java + test/tools/javac/annotations/neg/AnnComma.out ! test/tools/javac/annotations/neg/ArrayLit.java + test/tools/javac/annotations/neg/ArrayLit.out ! test/tools/javac/annotations/neg/Constant.java + test/tools/javac/annotations/neg/Constant.out ! test/tools/javac/annotations/neg/Cycle1.java + test/tools/javac/annotations/neg/Cycle1.out ! test/tools/javac/annotations/neg/Cycle2.java + test/tools/javac/annotations/neg/Cycle2.out ! test/tools/javac/annotations/neg/Cycle3.java + test/tools/javac/annotations/neg/Cycle3.out ! test/tools/javac/annotations/neg/Dup.java + test/tools/javac/annotations/neg/Dup.out ! test/tools/javac/annotations/neg/DupTarget.java + test/tools/javac/annotations/neg/DupTarget.out ! test/tools/javac/annotations/neg/MemberOver.java + test/tools/javac/annotations/neg/MemberOver.out Changeset: 9e6adccdd77f Author: sogoel Date: 2014-08-29 00:42 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9e6adccdd77f 8055074: Group 9a: golden files for tests in tools/javac dir Reviewed-by: jjg ! test/tools/javac/Ambig3.java + test/tools/javac/Ambig3.out ! test/tools/javac/BadAnnotation.java + test/tools/javac/BadAnnotation.out ! test/tools/javac/BadCovar.java + test/tools/javac/BadCovar.out ! test/tools/javac/BadHexConstant.java + test/tools/javac/BadHexConstant.out ! test/tools/javac/BoundClassError.java + test/tools/javac/BoundClassError.out ! test/tools/javac/BreakAcrossClass.java + test/tools/javac/BreakAcrossClass.out ! test/tools/javac/ClassIsAbstract.java + test/tools/javac/ClassIsAbstract.out ! test/tools/javac/ClassToTypeParm.java + test/tools/javac/ClassToTypeParm.out ! test/tools/javac/CompoundBox.java + test/tools/javac/CompoundBox.out Changeset: 9e29021d0d13 Author: alundblad Date: 2014-08-29 14:58 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9e29021d0d13 8056252: Incremental build fails on Windows Summary: Changed from '/' to File.separatorChar Reviewed-by: jfranck ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java Changeset: 9da59b2ab73d Author: mchung Date: 2014-08-29 10:46 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9da59b2ab73d 8055856: checkdeps build target doesn't work for cross-compilation builds 8056113: [build] tools.jar missing modules.xml Reviewed-by: ihse, erikj ! make/CompileInterim.gmk ! src/jdk.dev/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java ! src/jdk.dev/share/classes/com/sun/tools/jdeps/PlatformClassPath.java Changeset: 13705e2ddeb2 Author: lana Date: 2014-08-29 11:57 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/13705e2ddeb2 Merge Changeset: 5b2b0cde7f7b Author: katleman Date: 2014-09-04 13:26 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/5b2b0cde7f7b Added tag jdk9-b29 for changeset 13705e2ddeb2 ! .hgtags Changeset: 37e0edfac52e Author: sogoel Date: 2014-08-29 14:08 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/37e0edfac52e 8056288: Missing bug id in test/com/sun/javadoc/testOrdering/TestOrdering.java Reviewed-by: ksrini ! test/com/sun/javadoc/testOrdering/TestOrdering.java Changeset: 73b1d870a886 Author: mcimadamore Date: 2014-09-01 17:41 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/73b1d870a886 8057005: IntelliJ should allow import for nested classes Summary: Minor tweaks to langtools intellij project Reviewed-by: jfranck ! make/intellij/codeStyleSettings.xml ! make/intellij/copyright/profiles_settings.xml ! make/intellij/workspace.xml Changeset: c565b044f8c4 Author: kizune Date: 2014-09-03 19:22 +0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c565b044f8c4 8044597: Request to update tools/javap/T4501661.java to add test for package option Reviewed-by: jjg ! test/tools/javap/T4501661.java Changeset: 9a41fce5a626 Author: jjg Date: 2014-09-03 14:06 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9a41fce5a626 8034861: Incorrect format and indentation of InnerClasses section Reviewed-by: jjg, ksrini, mcimadamore, lagergren ! src/jdk.compiler/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/tools/javap/T4975569.java Changeset: b33de166fafb Author: jjg Date: 2014-09-03 14:19 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b33de166fafb 8038414: Constant pool's strings are not escaped properly Reviewed-by: jjg, mcimadamore, ksrini ! src/jdk.compiler/share/classes/com/sun/tools/javap/ConstantWriter.java + test/tools/javap/T8038414.java Changeset: 093d86cc0f8d Author: jlahoda Date: 2014-09-04 08:48 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/093d86cc0f8d 8054563: Update RunCodingRules.java for source code reorg Summary: Tests RunCodingRules and MessageInfo fixed to work in the new source code structure. Reviewed-by: jjg ! test/tools/all/RunCodingRules.java ! test/tools/javac/diags/MessageInfo.java Changeset: d898543d13fb Author: jlahoda Date: 2014-09-04 08:49 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/d898543d13fb 8047675: tools/javac/defaultMethods/Assertions.java fails if run with -enableassertions (-ea) Summary: Using ToolBox to start new Java processes, to avoid passing default VM options to the newly started process. Reviewed-by: jjg ! test/tools/javac/defaultMethods/Assertions.java + test/tools/javac/defaultMethods/AssertionsTest.java ! test/tools/lib/ToolBox.java Changeset: ef5427c13e1e Author: lana Date: 2014-09-04 14:45 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ef5427c13e1e Merge Changeset: a4843ba8f2dc Author: katleman Date: 2014-09-11 09:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a4843ba8f2dc Added tag jdk9-b30 for changeset ef5427c13e1e ! .hgtags Changeset: 0ecc0804ec11 Author: sogoel Date: 2014-09-04 16:52 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0ecc0804ec11 8055996: Remove @ignore from tools/javac/T6725036.java Reviewed-by: jjg ! test/tools/javac/T6725036.java Changeset: 0877f3c322c3 Author: sogoel Date: 2014-09-05 16:43 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0877f3c322c3 8055075: Group 9b: golden files for tests in tools/javac dir Reviewed-by: jjg ! test/tools/javac/ConditionalWithVoid.java + test/tools/javac/ConditionalWithVoid.out ! test/tools/javac/DuplicateClass.java + test/tools/javac/DuplicateClass.out ! test/tools/javac/EOI.java + test/tools/javac/EOI.out ! test/tools/javac/ExceptionalFinally2.java + test/tools/javac/ExceptionalFinally2.out ! test/tools/javac/ExprQualifiedType.java + test/tools/javac/ExprQualifiedType.out ! test/tools/javac/ExtendsScope.java + test/tools/javac/ExtendsScope.out ! test/tools/javac/ExtraneousEquals.java + test/tools/javac/ExtraneousEquals.out ! test/tools/javac/FlatnameClash2.java + test/tools/javac/FlatnameClash2.out ! test/tools/javac/InconsistentInheritedSignature.java + test/tools/javac/InconsistentInheritedSignature.out Changeset: ea62dc3a866e Author: sogoel Date: 2014-09-05 16:51 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ea62dc3a866e 8055079: Group 9c: golden files for tests in tools/javac dir Reviewed-by: jjg ! test/tools/javac/InterfaceObjectIncompatibility.java + test/tools/javac/InterfaceObjectIncompatibility.out ! test/tools/javac/InterfaceObjectInheritance.java + test/tools/javac/InterfaceObjectInheritance.out ! test/tools/javac/InterfaceOverrideFinal.java + test/tools/javac/InterfaceOverrideFinal.out ! test/tools/javac/LabeledDeclaration.java + test/tools/javac/LabeledDeclaration.out ! test/tools/javac/NestedDuplicateLabels.java + test/tools/javac/NestedDuplicateLabels.out ! test/tools/javac/NewGeneric.java + test/tools/javac/NewGeneric.out ! test/tools/javac/NoClass.java + test/tools/javac/NoClass.out ! test/tools/javac/Object1.java + test/tools/javac/Object1.out ! test/tools/javac/Object2.java + test/tools/javac/Object2.out Changeset: b545a2b1039d Author: jlahoda Date: 2014-09-08 10:48 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b545a2b1039d 8056014: Type inference may be skipped for a complex receiver generic method in a parameter position Summary: When checking if deferred attribution is needed for a chain of methods, stop on any method that returns any type variable, as the rest of analysis cannot use the correct type. Reviewed-by: mcimadamore, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/T8056014.java Changeset: d7e615e0115c Author: jlahoda Date: 2014-09-08 10:50 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/d7e615e0115c 8056984: Exception in compiler: java.lang.AssertionError: isSubClass T Summary: Must use type variable's captured bound as a method receiver, instead of the type variable itself, while checking if deferred attribution is needed. Reviewed-by: mcimadamore, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/T8056984.java Changeset: 8df25ec8c930 Author: jfranck Date: 2014-09-08 13:11 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8df25ec8c930 8056021: checkin for JDK-8027262 breaks Checker Framework Reviewed-by: jjg, mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TargetType.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Env.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.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/jvm/Gen.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/AllLocations.java ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out ! test/tools/javac/warnings/suppress/T6480588.java ! test/tools/javac/warnings/suppress/T6480588.out ! test/tools/javac/warnings/suppress/TypeAnnotations.java ! test/tools/javap/output/RepeatingTypeAnnotations.java Changeset: b27a7aae4b23 Author: mcimadamore Date: 2014-09-08 14:16 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b27a7aae4b23 8055514: Wrong, confusing error when non-static varargs referenced in static context Summary: Improved heuristics in MethodResolutionPhase.mergeResults() Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/8055514/T8055514.java + test/tools/javac/varargs/8055514/T8055514.out Changeset: 63711c189d79 Author: jlahoda Date: 2014-09-08 15:51 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/63711c189d79 8057753: Test langtools/test/tools/javac/NoClass.java is failing when run together with langtools/test/tools/javac/DuplicateImport.java Summary: Removing javac/NoClass test, as it is superseded by javac/importChecks/InvalidImportsNoClasses.java Reviewed-by: jfranck - test/tools/javac/NoClass.java - test/tools/javac/NoClass.out ! test/tools/javac/importChecks/InvalidImportsNoClasses.java Changeset: 10287adbf9d6 Author: pgovereau Date: 2014-09-09 11:55 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/10287adbf9d6 8055500: fix for 8030046 is incorrect Reviewed-by: jjg, ksrini ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java ! test/tools/javac/Paths/AbsolutePathTest.java Changeset: afb14d7db974 Author: pgovereau Date: 2014-09-09 12:16 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/afb14d7db974 8054210: NullPointerException when compiling specific code. Reviewed-by: vromero, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/flow/T8042741/LambdaArgumentsTest.java Changeset: 0d89f8b94872 Author: vromero Date: 2014-09-09 10:43 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0d89f8b94872 8042347: javac, Gen.LVTAssignAnalyzer should be refactored, it shouldn't be a static class Reviewed-by: mcimadamore, jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Bits.java Changeset: aa09fc6a3459 Author: lana Date: 2014-09-10 19:38 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/aa09fc6a3459 Merge - test/tools/javac/NoClass.java Changeset: d75456e839b5 Author: wetmore Date: 2014-09-11 12:18 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/d75456e839b5 8058180: .hgignore should be updated with webrev in all repos Reviewed-by: jrose, katleman, jjg ! .hgignore Changeset: 0046d55383a9 Author: lana Date: 2014-09-11 14:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0046d55383a9 Merge - test/tools/javac/NoClass.java Changeset: 414fb97e029d Author: katleman Date: 2014-09-17 22:56 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/414fb97e029d Added tag jdk9-b31 for changeset 0046d55383a9 ! .hgtags Changeset: 3eb8614e39b3 Author: sogoel Date: 2014-09-12 17:05 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3eb8614e39b3 8055080: Group 9d: golden files for tests in tools/javac dir Reviewed-by: jjg, mcimadamore, jlahoda ! test/tools/javac/Parens1.java + test/tools/javac/Parens1.out ! test/tools/javac/Parens2.java + test/tools/javac/Parens2.out ! test/tools/javac/Parens3.java + test/tools/javac/Parens3.out ! test/tools/javac/Parens4.java + test/tools/javac/Parens4.out ! test/tools/javac/ParseConditional.java + test/tools/javac/ParseConditional.out ! test/tools/javac/StoreClass.java + test/tools/javac/StoreClass.out ! test/tools/javac/SwitchScope.java + test/tools/javac/SwitchScope.out ! test/tools/javac/SynthName2.java + test/tools/javac/SynthName2.out ! test/tools/javac/T6234077.java + test/tools/javac/T6234077.out Changeset: c419bddef7f3 Author: mcimadamore Date: 2014-09-15 12:43 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c419bddef7f3 8055963: Inference failure with nested invocation Summary: Revise heuristics to force eager instantiation of return inference vars Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8055963/T8055963.java Changeset: 9a6c1bf0d19a Author: bpatel Date: 2014-09-17 23:52 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9a6c1bf0d19a 8043698: tag not getting generated in package-summary pages for un-named packages Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java Changeset: 7e15b8d4631d Author: bpatel Date: 2014-09-18 00:50 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/7e15b8d4631d 8047745: Javadoc should include encoding information in generated html files Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/testCharset/TestCharset.java Changeset: ad99965443d1 Author: lana Date: 2014-09-18 13:27 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ad99965443d1 Merge Changeset: fdefd7052a32 Author: katleman Date: 2014-09-25 12:40 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/fdefd7052a32 Added tag jdk9-b32 for changeset ad99965443d1 ! .hgtags Changeset: c67dc7a385b2 Author: sogoel Date: 2014-09-19 13:54 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c67dc7a385b2 8058755: Update tools/javadoc/6227454 to add head tag Reviewed-by: jjg ! test/tools/javadoc/6227454/Test.java Changeset: 2f8f2ae8a806 Author: jlahoda Date: 2014-09-22 14:55 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2f8f2ae8a806 8057794: Compiler Error when obtaining .class property Summary: Ensuring a non-null type and sym for illegal T.class to prevent downstream errors. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/T8057794.java + test/tools/javac/lambda/T8057794.out Changeset: ff1998c1ecab Author: emc Date: 2014-09-22 17:09 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ff1998c1ecab 8048614: Add TypeMetadata to contain type annotations and other type information Summary: Implement general framework for metadata on types Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeMetadata.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/types/TypeHarness.java Changeset: 3c7c7485fab7 Author: ntoda Date: 2014-09-25 13:54 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3c7c7485fab7 8050117: add to javac test Versions.java tests that show correct operation for source/target options pre 1.9 Reviewed-by: jjg ! test/tools/javac/versions/Versions.java Changeset: 180b0fc6cabf Author: lana Date: 2014-09-25 16:21 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/180b0fc6cabf Merge Changeset: e891e0c4edc5 Author: vromero Date: 2014-09-25 17:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e891e0c4edc5 8058708: java.lang.AssertionError compiling source code Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! test/tools/javac/flow/LVTHarness.java ! test/tools/javac/flow/tests/TestCaseIf.java Changeset: 49d692597e7b Author: lana Date: 2014-10-03 11:07 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/49d692597e7b Added tag jdk9-b33 for changeset e891e0c4edc5 ! .hgtags Changeset: 1a77eeed0c06 Author: bpatel Date: 2014-09-26 13:51 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/1a77eeed0c06 8048351: tidy errors for attribute href, name for langtools javadoc tests needs investigation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: ed691a10b8fc Author: sogoel Date: 2014-10-01 14:15 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ed691a10b8fc 8055783: Group 9e: golden files for tests in tools/javac dir Reviewed-by: jjg, mcimadamore ! test/tools/javac/T6306967.java + test/tools/javac/T6306967.out ! test/tools/javac/T6379327.java + test/tools/javac/T6379327.out ! test/tools/javac/T6407257.java + test/tools/javac/T6407257.out ! test/tools/javac/T6663588.java + test/tools/javac/T6663588.out ! test/tools/javac/UncaughtOverflow.java + test/tools/javac/UncaughtOverflow.out - test/tools/javac/UncaughtOverflow2.java ! test/tools/javac/UseEnum.java + test/tools/javac/UseEnum.out ! test/tools/javac/VoidArray.java + test/tools/javac/VoidArray.out Changeset: e18407fcede8 Author: lana Date: 2014-10-03 12:11 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e18407fcede8 Merge - test/tools/javac/UncaughtOverflow2.java Changeset: 00b00232dab6 Author: katleman Date: 2014-10-09 11:24 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/00b00232dab6 Added tag jdk9-b34 for changeset e18407fcede8 ! .hgtags Changeset: 7dcbcb75e42f Author: mcimadamore Date: 2014-10-15 13:58 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/7dcbcb75e42f merge with jdk9-b34 ! make/build.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.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/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.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/javap/AttributeWriter.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/JavacServiceImpl.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilerPool.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/CompilerThread.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacServer.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacService.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/JavacServiceClient.java - test/tools/javac/NoClass.java - test/tools/javac/UncaughtOverflow2.java ! test/tools/javac/failover/CheckAttributedTree.java + test/tools/javac/lambda/T8057794.out - test/tools/javac/lib/ToolBox.java From brian.goetz at oracle.com Wed Oct 15 14:19:37 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 15 Oct 2014 10:19:37 -0400 Subject: Static fields in specialized classes In-Reply-To: <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> Message-ID: <543E8279.10801@oracle.com> Let's take several steps back away from the "I want to continue programming with the reflective tools I was comfortable with in Java 1.0", and see if we can get at the heart of this "augh, different is scary!" reaction here that seems to be spreading. Forget for a second about whether the letters "List<int>.class" have semantic meaning in a .java file. We can certainly hide that, though I think (as I said yesterday) you'd probably ultimately complain if we did. The fundamental question for an implementation of generics is the mapping between types and classes. (List<String> is a type; List.class is a class.) In Java 1.0, there was a clean 1:1 mapping from types to classes. In Java 5, all instantiations of List<X>, for reference X, mapped to class List.class; this is an all-to-1 mapping. This is simple but everyone seems to think this is smelly and complains about it a lot. (Too bad, this aspect isn't going away.) In C++ templates, there is a clean 1:1 mapping again; every instantiation of list<x> is a distinct class, with no relationship to each other in the type system. But that distinctness means we give something up; for example, there is no "instanceof list" (or cast to list) because list is an infinite family of unrelated types. C# had the benefit of hindsight and designed their VM explicitly to support parametric polymorphism, including over value types. We don't have that benefit, and we're not going to redesign the VM for generics (sorry). So the question is, can we implement List<int> with the same class as we implement List<String>. Nearly all the other discomforts follow from this same issue (that's what instanceof means, for example). Can you do better? (I propose you think about this for a good long time before responding.) If you conclude that List<int> is represented by a different class than List<String>, now we get to ask some questions. Should I be able to reflect over the members of List<int>? Should I be able to ask whether something is an instance of List<int>? If so, we have a choice of how to spell this, but ultimately that's just a question of syntax, how we expose the reality into the surface language. Whether we add more to reflection -- and we certainly will have to -- is another matter, but I think your actual disagreement is with the representation of generic types by classes. (Anyone else find it amusing that people complain when generics are erased (all instantiations are represented by a single class), and then complain when they are not erased (different instantiations mapped to different classes)?) On 10/15/2014 9:48 AM, Paul Benedict wrote: > I throw my lot in with Ben and Stephen. I don't think specialization > should be exposed to the point that you can tell the difference with > .class. That's very disruptive to code and surprising. Rather, I think > you should expose more methods on Class to query the specialization type > -- that was something I recommended in the beginning and still favor. > > > Cheers, > Paul > > On Wed, Oct 15, 2014 at 3:30 AM, Ben Lewis <benlewisj at gmail.com > <mailto:benlewisj at gmail.com>> wrote: > > I think having Foo.class and Foo<int>.class be different is a mistake. > > class Person{} > > class Employee<any T> extends Bar{ > //lots of other stuff irrelevant to T > T getId(){ ? } > } > > Person p1=new Employee<Object>(); > Person p2=new Employee<int>(); > > As I understand it > > p1.class==Employee.class;//true > p2.class==Employee.class;//false > p1 instanceof Employee;//true > p2 instanceof Employee;//false > > How to determine b2 comes from ?source class? Employee? > > This will cause bugs in situations where the programmer expects how the > class hierarchy acts now rather than changing it to where specialisation > having a different class. This would also mean migrating <T> to <any T> > will cause backward compatibility issues. > > For example > > if(p instanceof Employee){ > //do something > }else{ > //do something else > } > > if written before specialisations It would do as expected but after > and if > p=new Employee<int>() it would execute the else block not as > expected when > the code is written. > > On Wed, Oct 15, 2014 at 12:59 PM, Brian Goetz > <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> > wrote: > > > My gut feeling is that this is undesirable and should be disallowed, > >> and that perhaps we shouldn't even be able to observe Foo<int>.class > >> at all. > >> > > > > If you think about the problem a little more, I think you'll find > that > > this is wishful thinking. (But of course, you're free to have a gut > > feeling without having thought about it at all.) > > > > After all, if specialization is intended to be viewed primarily > as an > >> implementation detail > >> > > > > It is an implementation detail in the same sense that erasure is; > that > > generics are implemented by erasure almost certainly leaks into > the user's > > perception too. (Erasure is why you can't have > Foo<String>.class, for > > example. Among many other things that the user has to pay > attention to.) > > > > class Foo<any T> { > > T get() { ... } > > } > > > > Consider the members of various instantiations of Foo. > > > > The signature of get() in Foo<String> is "String get()", but the > signature > > of get() in Foo<int> is "int get()". The erasure of the first is > "Object > > get()"; the erasure of the second is "int get()". While all erased > > reference instantiations can be implemented by the same class, the > > primitive/value instantiations cannot be. > > > > Similarly, Foo<int> can't extend Foo<?> (because that really > means Foo<? > > extends Object>, and has to for compatibility reasons), nor can > it extend > > raw Foo. (Which is fine; raw types exist solely to support > migration from > > ungenerified codebases to generified ones.) > > > > We could hide the existence of List<int>.class, but that would > just make > > life harder for users, who would then have to jump through bigger > hoops to > > reflect over the members of List<int> (which are different from > the members > > of List<String>, even after erasure.) > > > > In other words, while the Java language/library changes may be > >> expressed by some improvements to reflection, I'd be concerned about > >> the many implemented algorithms based on reflection. > >> > > > > It is of course reasonable to be concerned. Stay tuned and see > if your > > concerns are addressed. > > > > From brian.goetz at oracle.com Wed Oct 15 14:37:14 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 15 Oct 2014 10:37:14 -0400 Subject: Static fields in specialized classes In-Reply-To: <543E56FD.2000703@univ-mlv.fr> References: <543C17C3.50104@oracle.com> <CACzrW9BmCFat+=09ZgqaDz8nOv4GLhUExV-_GUvztJ7p3me3Kg@mail.gmail.com> <543D67B9.1000802@oracle.com> <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> <543D9968.10400@oracle.com> <E167BE2B-EB6F-45FC-9972-551D35E191A3@oracle.com> <543E56FD.2000703@univ-mlv.fr> Message-ID: <543E869A.5030105@oracle.com> Actually we're all being silly. Referencing the field at all will trigger initialization. No extra kicking needed. So if we have: class Foo<any T> { static int x = 3; void foo() { ... x ... } } the reference to Foo.x in Foo<int> will trigger initialization of Foo, causing its static initializers to run. On 10/15/2014 7:14 AM, Remi Forax wrote: > > On 10/15/2014 12:22 PM, Paul Sandoz wrote: >> On Oct 14, 2014, at 11:45 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote: >> >>>> - care might need to be taken with class initlization, static access >>>> should trigger initialisation before that access occurs but does this >>>> mean both Foo and Foo<int> should be initialized if access occurs >>>> from the latter? (not sure if you already have this aspect covered) >>> I think we have this one covered. The compiler and specializer >>> cooperate to have this effect. >>> >>> - All declarations of static members (fields and methods, including >>> <clinit>) are stripped out during specialization. So the static >>> members exist only on the template (base) class. >>> >>> - All references to static members (whether through classes or >>> through instances) are rewritten to directly reference the template >>> class. >>> >>> - Specialized classes acquire a <clinit> that does "LDC >>> template.class", idempotently forcing the template class to be >>> initialized if it is not already. >>> >> I am not sure an LDC is sufficient to guarantee initialization of the >> template class. See example program below. > > No, it doesn't. > LDC do load the class but the VM is not required to trigger the class > initialisation. > >> >> It may be necessary to invoke UNSAFE.ensureClassInitialized after the >> LDC of the class. >> >> If thats the case we could stuff a global UNSAFE instance in the >> constant pool when anonymously defining the class (much like direct >> method handles to fields). > > or to call an empty static method generated on purpose by javac. > >> >> Paul. > > R?mi > From scolebourne at joda.org Wed Oct 15 14:51:40 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 15 Oct 2014 15:51:40 +0100 Subject: Static fields in specialized classes In-Reply-To: <543DB8EE.6070801@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> Message-ID: <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> On 15 October 2014 00:59, Brian Goetz <brian.goetz at oracle.com> wrote: > (But of course, you're free to have a gut feeling without having thought about it at all.) I'm afraid I'm not paid to think full time about the issues like you are, but where I can and will speak up is where I have concerns about the "feel of Java" in future proposals. > Similarly, Foo<int> can't extend Foo<?> That is deeply unappealing. Given your explanation, I understand why it might be convenient to be defined that way, but that doesn't make it desirable. It depends on whether you view the "class" as just Foo or the whole of Foo<int>/Foo<T>. In some pieces of code, the method is acceptable the full type of Foo<String> or Foo<int>, but in other bits of code you just want to accept any Foo. If I write a method process(Foo<?>) today in Java 8, I expect it to be able to process a Foo with any generic (ie. I'm saying that I don't care about the generic parameter, and just want to use the other aspects of the class). To argue that in the future such a method will not be able to accept a Foo<int> (or any other value type) is as I said, deeply unappealing, and in a reasonable sense, not backwards compatible. Obviously alternative designs are hard, given that you've gone a fair way down the current specialism route. I believe that what I really want is for values to behave in code as fast objects, not for values to behave with all the quirks of primitives. (Primitives are bad, special cases in most framework code, and this thread appears to be expanding the scope of those bad, special cases, not reducing it). After all, I see no reason not to use value types very widely if done well, which means that as a library writer I can't predict whether my user has generified by a T or a value. > We could hide the existence of List<int>.class, but that would just make > life harder for users, who would then have to jump through bigger hoops to > reflect over the members of List<int> (which are different from the members > of List<String>, even after erasure.) Class members being a different type is a tricky problem after specialization. But one option would appear to be that viewed through Class, the type of the array is the standard Object[] with appropriate boxing. Only if you view through an additional "Specialized" lens would you get to see the difference. (I acknowledge that this would be not be easy to arrange and have other knock on effects, but they may be less surprising than what is proposed in this thread). Perhaps what Ben, Paul and I are ultimately saying is that the concept of the Class mapping to the piece of source code is valuable, and shouldn't be lost. As part of this, I don't consider it desirable to be able to overload like this: process(Foo<String>) process(Foo<int>) but not: process(Foo<String>) process(Foo<Integer>) It should be both or neither. Stephen From vitalyd at gmail.com Wed Oct 15 14:56:12 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 15 Oct 2014 10:56:12 -0400 Subject: Static fields in specialized classes In-Reply-To: <543E8279.10801@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> Message-ID: <CAHjP37GmwrNYSSK-F5SXtmuX9uWTopr3sRyLmjgnkAHNCWfjtg@mail.gmail.com> > > C# had the benefit of hindsight and designed their VM explicitly to > support parametric polymorphism, including over value types. We don't have > that benefit, and we're not going to redesign the VM for generics (sorry). For posterity, .NET gained generics in 2.0, which was about 4 yrs after initial release. They bit the bullet and made this first class (i.e. VM knows about it), but granted they had fewer years of history/compatibility (and user base) to deal with at the time. If you conclude that List<int> is represented by a different class than > List<String>, now we get to ask some questions. Should I be able to > reflect over the members of List<int>? Should I be able to ask whether > something is an instance of List<int>? If so, we have a choice of how to > spell this, but ultimately that's just a question of syntax, how we expose > the reality into the surface language. > My vote/answer would be "yes" to both of those questions. I'm not a fan of erasure though, so I'm biased :). > > Whether we add more to reflection -- and we certainly will have to -- is > another matter, but I think your actual disagreement is with the > representation of generic types by classes. > (Anyone else find it amusing that people complain when generics are erased > (all instantiations are represented by a single class), and then complain > when they are not erased (different instantiations mapped to different > classes)?) Yes, it's amusing but unsurprising given java's culture of preserving backwards compatibility at all cost. Personally, I worry that evolving the language with too much concern for preserving 10+yr old behavior is going to lead to clunky features. Perhaps there can be a java X release that simply breaks free of some baggage and people wanting to upgrade do their part in modifying their codebase accordingly? Wishful thinking, I know :) On Wed, Oct 15, 2014 at 10:19 AM, Brian Goetz <brian.goetz at oracle.com> wrote: > Let's take several steps back away from the "I want to continue > programming with the reflective tools I was comfortable with in Java 1.0", > and see if we can get at the heart of this "augh, different is scary!" > reaction here that seems to be spreading. > > Forget for a second about whether the letters "List<int>.class" have > semantic meaning in a .java file. We can certainly hide that, though I > think (as I said yesterday) you'd probably ultimately complain if we did. > > The fundamental question for an implementation of generics is the mapping > between types and classes. (List<String> is a type; List.class is a class.) > > In Java 1.0, there was a clean 1:1 mapping from types to classes. > > In Java 5, all instantiations of List<X>, for reference X, mapped to class > List.class; this is an all-to-1 mapping. This is simple but everyone seems > to think this is smelly and complains about it a lot. (Too bad, this aspect > isn't going away.) > > In C++ templates, there is a clean 1:1 mapping again; every instantiation > of list<x> is a distinct class, with no relationship to each other in the > type system. But that distinctness means we give something up; for > example, there is no "instanceof list" (or cast to list) because list is an > infinite family of unrelated types. > > C# had the benefit of hindsight and designed their VM explicitly to > support parametric polymorphism, including over value types. We don't have > that benefit, and we're not going to redesign the VM for generics (sorry). > > So the question is, can we implement List<int> with the same class as we > implement List<String>. Nearly all the other discomforts follow from this > same issue (that's what instanceof means, for example). Can you do > better? (I propose you think about this for a good long time before > responding.) > > If you conclude that List<int> is represented by a different class than > List<String>, now we get to ask some questions. Should I be able to > reflect over the members of List<int>? Should I be able to ask whether > something is an instance of List<int>? If so, we have a choice of how to > spell this, but ultimately that's just a question of syntax, how we expose > the reality into the surface language. > > Whether we add more to reflection -- and we certainly will have to -- is > another matter, but I think your actual disagreement is with the > representation of generic types by classes. > > (Anyone else find it amusing that people complain when generics are erased > (all instantiations are represented by a single class), and then complain > when they are not erased (different instantiations mapped to different > classes)?) > > On 10/15/2014 9:48 AM, Paul Benedict wrote: > >> I throw my lot in with Ben and Stephen. I don't think specialization >> should be exposed to the point that you can tell the difference with >> .class. That's very disruptive to code and surprising. Rather, I think >> you should expose more methods on Class to query the specialization type >> -- that was something I recommended in the beginning and still favor. >> >> >> Cheers, >> Paul >> >> On Wed, Oct 15, 2014 at 3:30 AM, Ben Lewis <benlewisj at gmail.com >> <mailto:benlewisj at gmail.com>> wrote: >> >> I think having Foo.class and Foo<int>.class be different is a >> mistake. >> >> class Person{} >> >> class Employee<any T> extends Bar{ >> //lots of other stuff irrelevant to T >> T getId(){ ? } >> } >> >> Person p1=new Employee<Object>(); >> Person p2=new Employee<int>(); >> >> As I understand it >> >> p1.class==Employee.class;//true >> p2.class==Employee.class;//false >> p1 instanceof Employee;//true >> p2 instanceof Employee;//false >> >> How to determine b2 comes from ?source class? Employee? >> >> This will cause bugs in situations where the programmer expects how >> the >> class hierarchy acts now rather than changing it to where >> specialisation >> having a different class. This would also mean migrating <T> to <any >> T> >> will cause backward compatibility issues. >> >> For example >> >> if(p instanceof Employee){ >> //do something >> }else{ >> //do something else >> } >> >> if written before specialisations It would do as expected but after >> and if >> p=new Employee<int>() it would execute the else block not as >> expected when >> the code is written. >> >> On Wed, Oct 15, 2014 at 12:59 PM, Brian Goetz >> <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> >> >> wrote: >> >> > My gut feeling is that this is undesirable and should be >> disallowed, >> >> and that perhaps we shouldn't even be able to observe >> Foo<int>.class >> >> at all. >> >> >> > >> > If you think about the problem a little more, I think you'll find >> that >> > this is wishful thinking. (But of course, you're free to have a >> gut >> > feeling without having thought about it at all.) >> > >> > After all, if specialization is intended to be viewed primarily >> as an >> >> implementation detail >> >> >> > >> > It is an implementation detail in the same sense that erasure is; >> that >> > generics are implemented by erasure almost certainly leaks into >> the user's >> > perception too. (Erasure is why you can't have >> Foo<String>.class, for >> > example. Among many other things that the user has to pay >> attention to.) >> > >> > class Foo<any T> { >> > T get() { ... } >> > } >> > >> > Consider the members of various instantiations of Foo. >> > >> > The signature of get() in Foo<String> is "String get()", but the >> signature >> > of get() in Foo<int> is "int get()". The erasure of the first is >> "Object >> > get()"; the erasure of the second is "int get()". While all erased >> > reference instantiations can be implemented by the same class, the >> > primitive/value instantiations cannot be. >> > >> > Similarly, Foo<int> can't extend Foo<?> (because that really >> means Foo<? >> > extends Object>, and has to for compatibility reasons), nor can >> it extend >> > raw Foo. (Which is fine; raw types exist solely to support >> migration from >> > ungenerified codebases to generified ones.) >> > >> > We could hide the existence of List<int>.class, but that would >> just make >> > life harder for users, who would then have to jump through bigger >> hoops to >> > reflect over the members of List<int> (which are different from >> the members >> > of List<String>, even after erasure.) >> > >> > In other words, while the Java language/library changes may be >> >> expressed by some improvements to reflection, I'd be concerned >> about >> >> the many implemented algorithms based on reflection. >> >> >> > >> > It is of course reasonable to be concerned. Stay tuned and see >> if your >> > concerns are addressed. >> > >> >> >> From vitalyd at gmail.com Wed Oct 15 15:03:54 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 15 Oct 2014 11:03:54 -0400 Subject: Static fields in specialized classes In-Reply-To: <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> Message-ID: <CAHjP37FbcktQXR74kKR0JQo45UzXRNdYzS1eU_wGR8ZegOuisQ@mail.gmail.com> > > Given your explanation, I understand why it might be convenient to be > defined that way, but that doesn't make it desirable. It depends on > whether you view the "class" as just Foo or the whole of > Foo<int>/Foo<T>. In some pieces of code, the method is acceptable the > full type of Foo<String> or Foo<int>, but in other bits of code you > just want to accept any Foo. If I write a method > process(Foo<?>) today in Java 8, I expect it to be able to process a Foo with any > generic (ie. I'm saying that I don't care about the generic parameter, > and just want to use the other aspects of the class). To argue that in > the future such a method will not be able to accept a Foo<int> (or any > other value type) is as I said, deeply unappealing, and in a > reasonable sense, not backwards compatible. Isn't the "right" way (forgetting current java generic issues for a second) to say "I can handle any generic Foo": <T> process(Foo<T>)? Finally, there's another alternative which is to have a base (non-generic) interface/class Foo, and then derive/extend a generic version Foo<T>. Code that doesn't care about the generic part accepts a Foo. Not saying that should be required, but another alternative if a generic method isn't wanted. As part of this, I don't consider it desirable to be able to overload like > this: > process(Foo<String>) > process(Foo<int>) > but not: > process(Foo<String>) > process(Foo<Integer>) It should be both or neither. That I fully agree with. On Wed, Oct 15, 2014 at 10:51 AM, Stephen Colebourne <scolebourne at joda.org> wrote: > On 15 October 2014 00:59, Brian Goetz <brian.goetz at oracle.com> wrote: > > (But of course, you're free to have a gut feeling without having thought > about it at all.) > > I'm afraid I'm not paid to think full time about the issues like you > are, but where I can and will speak up is where I have concerns about > the "feel of Java" in future proposals. > > > Similarly, Foo<int> can't extend Foo<?> > > That is deeply unappealing. > > Given your explanation, I understand why it might be convenient to be > defined that way, but that doesn't make it desirable. It depends on > whether you view the "class" as just Foo or the whole of > Foo<int>/Foo<T>. In some pieces of code, the method is acceptable the > full type of Foo<String> or Foo<int>, but in other bits of code you > just want to accept any Foo. If I write a method > > process(Foo<?>) > > today in Java 8, I expect it to be able to process a Foo with any > generic (ie. I'm saying that I don't care about the generic parameter, > and just want to use the other aspects of the class). To argue that in > the future such a method will not be able to accept a Foo<int> (or any > other value type) is as I said, deeply unappealing, and in a > reasonable sense, not backwards compatible. > > Obviously alternative designs are hard, given that you've gone a fair > way down the current specialism route. I believe that what I really > want is for values to behave in code as fast objects, not for values > to behave with all the quirks of primitives. (Primitives are bad, > special cases in most framework code, and this thread appears to be > expanding the scope of those bad, special cases, not reducing it). > After all, I see no reason not to use value types very widely if done > well, which means that as a library writer I can't predict whether my > user has generified by a T or a value. > > > We could hide the existence of List<int>.class, but that would just make > > life harder for users, who would then have to jump through bigger hoops > to > > reflect over the members of List<int> (which are different from the > members > > of List<String>, even after erasure.) > > Class members being a different type is a tricky problem after > specialization. But one option would appear to be that viewed through > Class, the type of the array is the standard Object[] with appropriate > boxing. Only if you view through an additional "Specialized" lens > would you get to see the difference. (I acknowledge that this would be > not be easy to arrange and have other knock on effects, but they may > be less surprising than what is proposed in this thread). > > Perhaps what Ben, Paul and I are ultimately saying is that the concept > of the Class mapping to the piece of source code is valuable, and > shouldn't be lost. > > As part of this, I don't consider it desirable to be able to overload like > this: > > process(Foo<String>) > process(Foo<int>) > > but not: > > process(Foo<String>) > process(Foo<Integer>) > > It should be both or neither. > > Stephen > From scolebourne at joda.org Wed Oct 15 15:11:10 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 15 Oct 2014 16:11:10 +0100 Subject: Static fields in specialized classes In-Reply-To: <543E8279.10801@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> Message-ID: <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> On 15 October 2014 15:19, Brian Goetz <brian.goetz at oracle.com> wrote: > The fundamental question for an implementation of generics is the mapping > between types and classes. (List<String> is a type; List.class is a class.) Isn't the issue that the class concept is being split into two different meanings? List<String> is a type (unchanged) List<int> and List<T> are distinct bytecode units List is the single piece of source code and overall concept Are we not debating which of the last two the current Class concept best maps to? I'm arguing that it is the concept that I want to refer to in code (instanceof, method signature, overloads), as that is far more common than a need to think about the bytecode unit (reflection). > In Java 5, all instantiations of List<X>, for reference X, mapped to class > List.class; this is an all-to-1 mapping. This is simple but everyone seems > to think this is smelly and complains about it a lot. I think those are mostly "noise" complaints. Developers have fully internalised this all to 1 mapping at this point and I'd disagree with the "everyone complains" statement. Stephen From pbenedict at apache.org Wed Oct 15 15:24:27 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 15 Oct 2014 10:24:27 -0500 Subject: Static fields in specialized classes In-Reply-To: <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> Message-ID: <CABLGb9zxqi5_L582XkGGmF2n78peZWJF6bF2Y8j3rrZPX8R2Zw@mail.gmail.com> For the record, I don't find it funny or annoying how erasures exist. I am generally content with the current all-to-1 mapping. I was hoping when valhalla started, the implementation sought would be to unify primitives and objects into one type hierarchy (could be represented in <?>), but the current implementation does seem to further the schism of objects and primitives. Schisms are bad. I agree with Stephen again on this. I think specializing with primitives should keep the current all-to-1 mapping -- despite whatever happens to the bytecode underneath. Cheers, Paul On Wed, Oct 15, 2014 at 10:11 AM, Stephen Colebourne <scolebourne at joda.org> wrote: > On 15 October 2014 15:19, Brian Goetz <brian.goetz at oracle.com> wrote: > > The fundamental question for an implementation of generics is the mapping > > between types and classes. (List<String> is a type; List.class is a > class.) > > Isn't the issue that the class concept is being split into two > different meanings? > > List<String> is a type (unchanged) > List<int> and List<T> are distinct bytecode units > List is the single piece of source code and overall concept > > Are we not debating which of the last two the current Class concept > best maps to? > > I'm arguing that it is the concept that I want to refer to in code > (instanceof, method signature, overloads), as that is far more common > than a need to think about the bytecode unit (reflection). > > > > In Java 5, all instantiations of List<X>, for reference X, mapped to > class > > List.class; this is an all-to-1 mapping. This is simple but everyone > seems > > to think this is smelly and complains about it a lot. > > I think those are mostly "noise" complaints. Developers have fully > internalised this all to 1 mapping at this point and I'd disagree with > the "everyone complains" statement. > > Stephen > From brian.goetz at oracle.com Wed Oct 15 15:25:58 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 15 Oct 2014 11:25:58 -0400 Subject: Static fields in specialized classes In-Reply-To: <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> Message-ID: <543E9206.5070109@oracle.com> > I'm afraid I'm not paid to think full time about the issues like you > are, but where I can and will speak up is where I have concerns about > the "feel of Java" in future proposals. You're free to speak up. I would hope that before doing so, you'll first make a fair attempt to learn what is being proposed, rather than shooting from the hip based on your first glimpse of what "new generics" might look like. It takes some time to get used to new ideas. (Remember, people bitched mightily about how complicated generics were when they were introduced.) >> Similarly, Foo<int> can't extend Foo<?> > > That is deeply unappealing. I don't disagree, though I might quibble about the depth of "deeply". I'll just note that the alternatives in evidence are less appealing. > just want to accept any Foo. If I write a method > > process(Foo<?>) > > today in Java 8, I expect it to be able to process a Foo with any > generic I'll accept the goal -- it is essential that a method can process any Foo<T>. Just not the mechanism -- see below. > (ie. I'm saying that I don't care about the generic parameter, > and just want to use the other aspects of the class). To argue that in > the future such a method will not be able to accept a Foo<int> (or any > other value type) is as I said, deeply unappealing, and in a > reasonable sense, not backwards compatible. I would argue that the trick of simulating generic methods with process(Foo<?>) was *always* broken. (Collections does this for backward compatibility with pre-generified collections, but this was always a trick for migration, not for simulating generic methods.) What you should have done even in Java 5 was <T> void process(Foo<T>) { ... } instead. It's just that because of erasure, you could get away without using the wildcard parameter and nothing bad happens. So yes, you will no longer be able to get away with that trick for any-generic T, but you will still be able to use the right tool -- generic methods -- to write fully generic code. So if you want to write methods that are generic across all Foo<T> instantiations, just do: <any T> void process(Foo<T> foo) { ... } and you're fine. So if the complaint is "I need to be able to write a method that accepts any Foo<T>", we're way ahead of you -- use the tool that was always there for that, it will work just fine. If the complaint is "I want to continue to use things that only work in an erased world in a semi-reified world", well, you're going to need to let go of your crutch. Refactoring void process(Foo<?>) into <any T> void process(Foo<T>) is not hard. And there's no backward-compatibility issue -- existing code will continue to work as before. > Obviously alternative designs are hard, given that you've gone a fair > way down the current specialism route. I believe that what I really > want is for values to behave in code as fast objects, not for values > to behave with all the quirks of primitives. Yeah, that's a nice idea, and it might be possible to get that at the boundary (where values are passed from one method to another.) Where this falls down is in representation of things like arrays; you want ArrayList<int> to be backed by an int[], not an Integer[]. You may be able to make boxing faster (and we should!), but when the data hits the heap, erasure won't cut it. > (Primitives are bad, > special cases in most framework code, and this thread appears to be > expanding the scope of those bad, special cases, not reducing it). I think you will find you are wrong about that. This is unifying the treatment of primitives in generics, which is one part of the puzzle; there are others, but when we're done, we should be finished with silliness like writing nine versions of methods like Arrays.fill. Avoiding special-casing of primitives is part of the design goal here, by unifying all primitives in the greater family of "values". > Perhaps what Ben, Paul and I are ultimately saying is that the concept > of the Class mapping to the piece of source code is valuable, and > shouldn't be lost. Yes, this is the important part, and it wasn't lost on me. People have intuitive ideas of what "instanceof Foo" means, and that is important. > As part of this, I don't consider it desirable to be able to overload like this: > > process(Foo<String>) > process(Foo<int>) > > but not: > > process(Foo<String>) > process(Foo<Integer>) > > It should be both or neither. This is a valid opinion -- though not the only valid opinion! This is a place where we have a choice; keep the existing rules (on the theory that people have finally figured them out), or extend them based on what is possible (on the theory that we should make the restrictions as minimal as they can be.) And either way will upset someone! So this is one of those stewardship choices the EG will get to eventually make. (A nearly identical one is "implements Comparable<int>, Comparable<long>".) From brian.goetz at oracle.com Wed Oct 15 15:32:49 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 15 Oct 2014 11:32:49 -0400 Subject: Static fields in specialized classes In-Reply-To: <CABLGb9zxqi5_L582XkGGmF2n78peZWJF6bF2Y8j3rrZPX8R2Zw@mail.gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> <CABLGb9zxqi5_L582XkGGmF2n78peZWJF6bF2Y8j3rrZPX8R2Zw@mail.gmail.com> Message-ID: <543E93A1.5070007@oracle.com> In a perfect world, of course that's what we'd do. For examples of how the world is imperfect, I refer you to the experience of Scala in trying to unify primitives and references -- it was a disaster. (See Paul Philip's talk at JVMLS 2013 for one example of this.) In light of this, our conclusion is that the schism between values and references is real, and what is needed is to treat it in a less ad-hoc way, but not make attempts to hide it, since such attempts usually fail (and when they do, the failures are even more painful.) Is this unfortunate? Sure. Should we give up because its hard? Of course not. On 10/15/2014 11:24 AM, Paul Benedict wrote: > For the record, I don't find it funny or annoying how erasures exist. I am > generally content with the current all-to-1 mapping. I was hoping when > valhalla started, the implementation sought would be to unify primitives > and objects into one type hierarchy (could be represented in <?>), but the > current implementation does seem to further the schism of objects and > primitives. Schisms are bad. I agree with Stephen again on this. I think > specializing with primitives should keep the current all-to-1 mapping -- > despite whatever happens to the bytecode underneath. > > > Cheers, > Paul > > On Wed, Oct 15, 2014 at 10:11 AM, Stephen Colebourne <scolebourne at joda.org> > wrote: > >> On 15 October 2014 15:19, Brian Goetz <brian.goetz at oracle.com> wrote: >>> The fundamental question for an implementation of generics is the mapping >>> between types and classes. (List<String> is a type; List.class is a >> class.) >> >> Isn't the issue that the class concept is being split into two >> different meanings? >> >> List<String> is a type (unchanged) >> List<int> and List<T> are distinct bytecode units >> List is the single piece of source code and overall concept >> >> Are we not debating which of the last two the current Class concept >> best maps to? >> >> I'm arguing that it is the concept that I want to refer to in code >> (instanceof, method signature, overloads), as that is far more common >> than a need to think about the bytecode unit (reflection). >> >> >>> In Java 5, all instantiations of List<X>, for reference X, mapped to >> class >>> List.class; this is an all-to-1 mapping. This is simple but everyone >> seems >>> to think this is smelly and complains about it a lot. >> >> I think those are mostly "noise" complaints. Developers have fully >> internalised this all to 1 mapping at this point and I'd disagree with >> the "everyone complains" statement. >> >> Stephen >> From brian.goetz at oracle.com Wed Oct 15 18:35:57 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 15 Oct 2014 18:35:57 +0000 Subject: hg: valhalla/valhalla/jdk: Partial support for specializing static generic methods Message-ID: <201410151835.s9FIZwXB004303@aojmv0008> Changeset: 1cfe92016a7b Author: briangoetz Date: 2014-10-15 14:35 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/1cfe92016a7b Partial support for specializing static generic methods ! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java + test/valhalla/test/valhalla/specializer/GenericMethodsTest.java + test/valhalla/test/valhalla/specializer/MiscManglingsTest.java - test/valhalla/test/valhalla/specializer/TestMiscManglings.java ! test/valhalla/test/valhalla/specializer/TwoBox.java ! test/valhalla/test/valhalla/specializer/TwoBoxTest.java From brian.goetz at oracle.com Wed Oct 15 22:37:43 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 15 Oct 2014 22:37:43 +0000 Subject: hg: valhalla/valhalla/jdk: More support for generic static methods Message-ID: <201410152237.s9FMbhMj015628@aojmv0008> Changeset: 29ca9426b7a0 Author: briangoetz Date: 2014-10-15 18:32 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/29ca9426b7a0 More support for generic static methods ! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! test/valhalla/test/valhalla/specializer/GenericMethodsTest.java From scolebourne at joda.org Wed Oct 15 23:14:38 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 16 Oct 2014 00:14:38 +0100 Subject: Static fields in specialized classes In-Reply-To: <543E9206.5070109@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> <543E9206.5070109@oracle.com> Message-ID: <CACzrW9C7Zz2=rKrabUwtO1D2QPt+4kayM6F0OMuSh7jJyeDr-g@mail.gmail.com> On 15 October 2014 16:25, Brian Goetz <brian.goetz at oracle.com> wrote: > What you should have done even in Java 5 was > <T> void process(Foo<T>) { ... } Thats an argument to get developers to type more code for no actual benefit (in Java 5 to 8). Not very appealing. > So if you want to write methods that are generic across all > Foo<T> instantiations, just do: > <any T> void process(Foo<T> foo) { ... } > and you're fine. Not quite. It is not possible to write code in Java 8 that still works in Java 10. While a private closed code base can potentially make the change you propose when migrating to 10, an open source library can't. As an open source author, I need the code I publish to be equally usable across multiple Java versions. I can't write <any T> today, so it won't work as desired in 10. The "refactor and you're fine" argument doesn't work here. (Conceptually, "any T" is a new supertype of Object and primitive, which is an understandable design choice, but of little use to running code both pre and post 10) > Where this > falls down is in representation of things like arrays; you want > ArrayList<int> to be backed by an int[], not an Integer[]. You may be able > to make boxing faster (and we should!), but when the data hits the heap, > erasure won't cut it. We obviously want int[] or value[] not Object[]. What I was suggesting is that if an int[] is accessed via a dumb Object[] reflection routine then boxing occurs. If accessed via a smart, specialism aware reflection routine, then the int[] is visible. Think of it as a variation of boxing that applies to arrays instead of single objects. > Avoiding special-casing > of primitives is part of the design goal here, by unifying all primitives in > the greater family of "values". I'm glad to hear that, but I'm not yet seeing it. In fact I'm seeing the opposite, because that sentence implies unifying primitives and values, rather than unifying primitives and objects. Perhaps this is an understanding issue. Perhaps it is an early stage issue. But my "I want a pony" requirement is still for int and value to "just be" a kind of Object (difficulty noted, and where Object is no longer a synonym for reference type). Stephen From brian.goetz at oracle.com Thu Oct 16 00:11:51 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 15 Oct 2014 20:11:51 -0400 Subject: Static fields in specialized classes In-Reply-To: <CACzrW9C7Zz2=rKrabUwtO1D2QPt+4kayM6F0OMuSh7jJyeDr-g@mail.gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> <543E9206.5070109@oracle.com> <CACzrW9C7Zz2=rKrabUwtO1D2QPt+4kayM6F0OMuSh7jJyeDr-g@mail.gmail.com> Message-ID: <543F0D47.4000400@oracle.com> > Not quite. It is not possible to write code in Java 8 that still works > in Java 10. Here's an idea: let's hold off on the "it is not possible" claims until you've actually seen the whole story. Addressing your concern, though, we do care deeply about migration compatibility; it was a huge goal of generics to allow codebases to generify gradually without requiring a flag day across maintenance domains. (This is why we still have raw types.) Gradual any-generification poses a similar requirement, and we will not ignore the situation of migrating old generic code that didn't know about any-generics. (We have this very problem with our own Collections, which are full of leftovers from 5-migration-compatibility like removeAll(Collection<?>)). > While a private closed code base can potentially make the > change you propose when migrating to 10, an open source library can't. > As an open source author, I need the code I publish to be equally > usable across multiple Java versions. I can't write <any T> today, so > it won't work as desired in 10. The "refactor and you're fine" > argument doesn't work here. Yeah, this is a problem with every nontrivial new language feature; that's pretty much independent of anything we've been discussing here. The good news is that we're working on a separate initiative to ease this pain, which is felt by all libraries. Historically the approach libraries have taken is a least-common-denominator one; this was generally OK because the platform had not been evolving all that fast, so 5 was a reasonable least-common-denominator for a while. But now that things are actually evolving again, and people want to actually use the new features, this becomes important. We see this with libraries that want to use lambdas as well, but also want to maintain a single binary artifact. So, stay tuned. From daniel.latremoliere at gmail.com Thu Oct 16 06:13:29 2014 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Thu, 16 Oct 2014 08:13:29 +0200 Subject: Static fields in specialized classes In-Reply-To: <543E93A1.5070007@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> <CABLGb9zxqi5_L582XkGGmF2n78peZWJF6bF2Y8j3rrZPX8R2Zw@mail.gmail.com> <543E93A1.5070007@oracle.com> Message-ID: <543F6209.2070504@gmail.com> > In light of this, our conclusion is that the schism between values and > references is real, and what is needed is to treat it in a less ad-hoc > way, but not make attempts to hide it, since such attempts usually > fail (and when they do, the failures are even more painful.) When I see String/StringBuffer/StringBuilder or int/Integer/AtomicInteger, I am concerned by the number of needed schisms and the excessive use of similar but different absolute names for similar notions. Can you say which schisms are real in the characteristics of objects, like: - pass by reference or by value - has identity or not - mutability or not - thread-safety or not - possible others [1]. Is it needed by schisms to use different absolute names or is type needing a definition by combining an unique absolute name, like java.lang.Integer with needed characteristics, using something similar to JSR 308. By example, can int be redesigned as a default shortcut of something like @IdentityLess Integer (but with annotation modifying behaviour, contrary to current annotations). [1]: In the following link, you can find some others possible generic characteristics of a type, like: nullness, interning, tainting, units, etc. http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html Thanks. From forax at univ-mlv.fr Thu Oct 16 09:58:06 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 16 Oct 2014 11:58:06 +0200 Subject: Static fields in specialized classes In-Reply-To: <543E869A.5030105@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9BmCFat+=09ZgqaDz8nOv4GLhUExV-_GUvztJ7p3me3Kg@mail.gmail.com> <543D67B9.1000802@oracle.com> <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> <543D9968.10400@oracle.com> <E167BE2B-EB6F-45FC-9972-551D35E191A3@oracle.com> <543E56FD.2000703@univ-mlv.fr> <543E869A.5030105@oracle.com> Message-ID: <543F96AE.6050508@univ-mlv.fr> On 10/15/2014 04:37 PM, Brian Goetz wrote: > Actually we're all being silly. Referencing the field at all will > trigger initialization. No extra kicking needed. > > So if we have: > > class Foo<any T> { > static int x = 3; > > void foo() { ... x ... } > } > > the reference to Foo.x in Foo<int> will trigger initialization of Foo, > causing its static initializers to run. yes, but not at the right time :( class Foo<any T> { static int x; static { System.out.println("init"); x = 2; } void foo() { System.out.println("foo"); ... x ... } } new Foo<int>().foo() will print "foo" then "init" instead of "init" then "foo". R?mi > > On 10/15/2014 7:14 AM, Remi Forax wrote: >> >> On 10/15/2014 12:22 PM, Paul Sandoz wrote: >>> On Oct 14, 2014, at 11:45 PM, Brian Goetz <brian.goetz at Oracle.COM> >>> wrote: >>> >>>>> - care might need to be taken with class initlization, static access >>>>> should trigger initialisation before that access occurs but does this >>>>> mean both Foo and Foo<int> should be initialized if access occurs >>>>> from the latter? (not sure if you already have this aspect covered) >>>> I think we have this one covered. The compiler and specializer >>>> cooperate to have this effect. >>>> >>>> - All declarations of static members (fields and methods, including >>>> <clinit>) are stripped out during specialization. So the static >>>> members exist only on the template (base) class. >>>> >>>> - All references to static members (whether through classes or >>>> through instances) are rewritten to directly reference the template >>>> class. >>>> >>>> - Specialized classes acquire a <clinit> that does "LDC >>>> template.class", idempotently forcing the template class to be >>>> initialized if it is not already. >>>> >>> I am not sure an LDC is sufficient to guarantee initialization of the >>> template class. See example program below. >> >> No, it doesn't. >> LDC do load the class but the VM is not required to trigger the class >> initialisation. >> >>> >>> It may be necessary to invoke UNSAFE.ensureClassInitialized after the >>> LDC of the class. >>> >>> If thats the case we could stuff a global UNSAFE instance in the >>> constant pool when anonymously defining the class (much like direct >>> method handles to fields). >> >> or to call an empty static method generated on purpose by javac. >> >>> >>> Paul. >> >> R?mi >> From scolebourne at joda.org Thu Oct 16 10:25:33 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 16 Oct 2014 11:25:33 +0100 Subject: Static fields in specialized classes In-Reply-To: <543F0D47.4000400@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CACzrW9DD1rsnchKp6oQOJTpEKhzWHeprrjhLHbU8HROwe-Sp0g@mail.gmail.com> <543E9206.5070109@oracle.com> <CACzrW9C7Zz2=rKrabUwtO1D2QPt+4kayM6F0OMuSh7jJyeDr-g@mail.gmail.com> <543F0D47.4000400@oracle.com> Message-ID: <CACzrW9D59JSL3yCcDKZfP8sQdgxXU8wFGQAV-oD2H-SwYkiDqQ@mail.gmail.com> On 16 October 2014 01:11, Brian Goetz <brian.goetz at oracle.com> wrote: >> While a private closed code base can potentially make the >> change you propose when migrating to 10, an open source library can't. >> As an open source author, I need the code I publish to be equally >> usable across multiple Java versions. I can't write <any T> today, so >> it won't work as desired in 10. The "refactor and you're fine" >> argument doesn't work here. > > Yeah, this is a problem with every nontrivial new language feature; that's > pretty much independent of anything we've been discussing here. > > The good news is that we're working on a separate initiative to ease this > pain, which is felt by all libraries. Historically the approach libraries > have taken is a least-common-denominator one; this was generally OK because > the platform had not been evolving all that fast, so 5 was a reasonable > least-common-denominator for a while. But now that things are actually > evolving again, and people want to actually use the new features, this > becomes important. We see this with libraries that want to use lambdas as > well, but also want to maintain a single binary artifact. So, stay tuned. Cool. I look forward to the next rabbit out of the hat (but obviously it can make it hard for us outsiders to comment on things as they currently stand). Stephen From paul.sandoz at oracle.com Thu Oct 16 11:57:45 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Oct 2014 13:57:45 +0200 Subject: Static fields in specialized classes In-Reply-To: <543F96AE.6050508@univ-mlv.fr> References: <543C17C3.50104@oracle.com> <CACzrW9BmCFat+=09ZgqaDz8nOv4GLhUExV-_GUvztJ7p3me3Kg@mail.gmail.com> <543D67B9.1000802@oracle.com> <118F322D-D41D-4587-BF67-D2DD299B6CBE@oracle.com> <543D9968.10400@oracle.com> <E167BE2B-EB6F-45FC-9972-551D35E191A3@oracle.com> <543E56FD.2000703@univ-mlv.fr> <543E869A.5030105@oracle.com> <543F96AE.6050508@univ-mlv.fr> Message-ID: <514A460F-FDCB-4574-8587-FD2C301FC355@oracle.com> On Oct 16, 2014, at 11:58 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > On 10/15/2014 04:37 PM, Brian Goetz wrote: >> Actually we're all being silly. Referencing the field at all will trigger initialization. No extra kicking needed. >> >> So if we have: >> >> class Foo<any T> { >> static int x = 3; >> >> void foo() { ... x ... } >> } >> >> the reference to Foo.x in Foo<int> will trigger initialization of Foo, causing its static initializers to run. > > yes, but not at the right time :( > That depends :-) From what i gather we don't have to bake in an intialization dependency between the template class and the specialized class, so perhaps we should not set any expectations, especially if such expectations falsely suggest a hierarchical class relationship when there is none. Paul. > class Foo<any T> { > static int x; > static { > System.out.println("init"); > x = 2; > } > > void foo() { > System.out.println("foo"); > ... x ... > } > } > > new Foo<int>().foo() > > will print "foo" then "init" instead of "init" then "foo". > > R?mi From brian.goetz at oracle.com Thu Oct 16 13:20:05 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 16 Oct 2014 09:20:05 -0400 Subject: Static fields in specialized classes In-Reply-To: <543F6209.2070504@gmail.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> <CABLGb9zxqi5_L582XkGGmF2n78peZWJF6bF2Y8j3rrZPX8R2Zw@mail.gmail.com> <543E93A1.5070007@oracle.com> <543F6209.2070504@gmail.com> Message-ID: <543FC605.40305@oracle.com> I could spend infinite hours answering questions like these and others, and it would be a very interesting discussion, but I think its a better use of our resources to focus on designing and building, so you'll forgive me if I don't answer all of these questions immediately. But I'll just note that the @IdentityLess annotation notion is a decent mental model for what value types will be. Take away identity, and you have to give up some things -- specifically mutability and polymorphism. (C# went through some pretty big hoops to do mutable value types, which acquire the identity of whatever contained them, and later admitted that had been a pretty dumb thing to do.) So the entire exercise for value types is essentially pulling on the string of "what does it mean to have aggregates without identity." On 10/16/2014 2:13 AM, Daniel Latr?moli?re wrote: > >> In light of this, our conclusion is that the schism between values and >> references is real, and what is needed is to treat it in a less ad-hoc >> way, but not make attempts to hide it, since such attempts usually >> fail (and when they do, the failures are even more painful.) > > When I see String/StringBuffer/StringBuilder or > int/Integer/AtomicInteger, I am concerned by the number of needed > schisms and the excessive use of similar but different absolute names > for similar notions. Can you say which schisms are real in the > characteristics of objects, like: > > - pass by reference or by value > - has identity or not > - mutability or not > - thread-safety or not > - possible others [1]. > > Is it needed by schisms to use different absolute names or is type > needing a definition by combining an unique absolute name, like > java.lang.Integer with needed characteristics, using something similar > to JSR 308. By example, can int be redesigned as a default shortcut of > something like @IdentityLess Integer (but with annotation modifying > behaviour, contrary to current annotations). > > [1]: In the following link, you can find some others possible generic > characteristics of a type, like: nullness, interning, tainting, units, etc. > http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html > > > Thanks. > From daniel.latremoliere at gmail.com Thu Oct 16 16:08:02 2014 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Thu, 16 Oct 2014 18:08:02 +0200 Subject: Static fields in specialized classes In-Reply-To: <543FC605.40305@oracle.com> References: <543C17C3.50104@oracle.com> <CACzrW9Aypn+Nq7j+x0PAefHgseAkZYd=-LJGj6kBX4vmxMVXBg@mail.gmail.com> <543DB8EE.6070801@oracle.com> <CAD4jWF9-wkSDXwM6WcNCZO2TMiaMuFOyK6F9L-jPanRPhbr_Bg@mail.gmail.com> <CABLGb9xkqRpg4WHh-6pZaJu1X6WCvakHrw-MNrx4-Q78CsPpWA@mail.gmail.com> <543E8279.10801@oracle.com> <CACzrW9CET_sS_yi_i6bFHAiA6eQhg5Rh69xYtsfPCktU8Xozwg@mail.gmail.com> <CABLGb9zxqi5_L582XkGGmF2n78peZWJF6bF2Y8j3rrZPX8R2Zw@mail.gmail.com> <543E93A1.5070007@oracle.com> <543F6209.2070504@gmail.com> <543FC605.40305@oracle.com> Message-ID: <543FED62.5050003@gmail.com> > I could spend infinite hours answering questions like these and > others, and it would be a very interesting discussion, but I think its > a better use of our resources to focus on designing and building, so > you'll forgive me if I don't answer all of these questions immediately. OK, I will see in the future, hoping only that Valhalla will build more on less on current Java8 features/ideas, like pluggable type system (JSR 308) concepts, to avoid explosion in the number of identifiers in type system (replaced by aggregation of optional features required by caller around the class identifier). In practice, I only hope, for simplicity of Java, that Java 9 will not add two new classes (with corresponding new identifiers) for each common class: by example, for List<Object>, will not add a value type like List<int> and an observable type like ObservableList<Object> (if JavaFX JSR is in Java9). I wish you a good focus on design and build and shut my mouth. From maurizio.cimadamore at oracle.com Fri Oct 17 12:02:28 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 17 Oct 2014 12:02:28 +0000 Subject: hg: valhalla/valhalla/langtools: Tweak rules for generating accessors to statics. Message-ID: <201410171202.s9HC2S1n019337@aojmv0008> Changeset: 3bdde8f34f6b Author: mcimadamore Date: 2014-10-17 12:59 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3bdde8f34f6b Tweak rules for generating accessors to statics. * access to private static members should always go through accessors, even in cases where the accessed symbol is in the same _specializable_ class. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/valhalla/typespec/Statics02.java From brian.goetz at oracle.com Fri Oct 17 15:40:20 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 17 Oct 2014 15:40:20 +0000 Subject: hg: valhalla/valhalla/jdk: Adjust names of generated classes to avoid verification errors Message-ID: <201410171540.s9HFeLjg029760@aojmv0008> Changeset: 0dbd3eb4c583 Author: briangoetz Date: 2014-10-17 11:40 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0dbd3eb4c583 Adjust names of generated classes to avoid verification errors ! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java From maurizio.cimadamore at oracle.com Mon Oct 20 13:20:39 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 20 Oct 2014 13:20:39 +0000 Subject: hg: valhalla/valhalla/langtools: Fix bugs in inner class specialization. Message-ID: <201410201320.s9KDKd1o015840@aojmv0008> Changeset: 06ebcca65d13 Author: mcimadamore Date: 2014-10-20 14:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/06ebcca65d13 Fix bugs in inner class specialization. * Fix inconsistent numbering in inner class specialized tvar names * Fix NPEs caused by caching logic stashing 'noType' as placeholders for non-specialized tvars * cleanup logic for mapping unspecialized tvars to specialized tvars * add basic smoke test ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/List.java + test/tools/javac/valhalla/typespec/Inner01.java From maurizio.cimadamore at oracle.com Mon Oct 20 17:17:49 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 20 Oct 2014 17:17:49 +0000 Subject: hg: valhalla/valhalla/langtools: Tweak TypeVariablesMap attribute to mention enclosing contexts. Message-ID: <201410201717.s9KHHnCV024075@aojmv0008> Changeset: 8198a8a48298 Author: mcimadamore Date: 2014-10-20 18:17 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8198a8a48298 Tweak TypeVariablesMap attribute to mention enclosing contexts. * Change the structure of the TypeVariableMap, so as to contain a list of entries, each of which corresponds to a lexically enclosing scope declaring some type-variables. This allows for fast type-variable lookups, which can be achieved w/o looking into InnerClass and EnclosingMethod attributes. ! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/TypeVariablesMap_attribute.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/javap/AttributeWriter.java From maurizio.cimadamore at oracle.com Mon Oct 20 17:19:31 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 20 Oct 2014 17:19:31 +0000 Subject: hg: valhalla/valhalla/jdk: Misc fixes to handle new TypeVariableMap attribute Message-ID: <201410201719.s9KHJVUw024408@aojmv0008> Changeset: c1f312421423 Author: mcimadamore Date: 2014-10-20 18:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/c1f312421423 Misc fixes to handle new TypeVariableMap attribute * update ASM representation of TVM attribute * tweak the specializer to only use the innermost TVM context ! src/java.base/share/classes/valhalla/specializer/Specialize.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! src/java.base/share/classes/valhalla/specializer/TypeVariablesMapAttribute.java From paul.sandoz at oracle.com Wed Oct 22 16:25:45 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 22 Oct 2014 16:25:45 +0000 Subject: hg: valhalla/valhalla/jdk: VarHandles for int/long arrays. Message-ID: <201410221625.s9MGPkQC014289@aojmv0008> Changeset: fff1c746733f Author: psandoz Date: 2014-10-22 18:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fff1c746733f VarHandles for int/long arrays. + src/java.base/share/classes/java/lang/invoke/ArrayIntHandle.java + src/java.base/share/classes/java/lang/invoke/ArrayLongHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! test/java/lang/invoke/VarHandleTest.java From maurizio.cimadamore at oracle.com Wed Oct 22 19:11:21 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 22 Oct 2014 19:11:21 +0000 Subject: hg: valhalla/valhalla/langtools: Add initial conditional method support: Message-ID: <201410221911.s9MJBL4A013465@aojmv0008> Changeset: 3ffc6541ddba Author: mcimadamore Date: 2014-10-22 20:10 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3ffc6541ddba Add initial conditional method support: * __RefOnly keyword can be used to tag methods that should only be available on 'erased' receivers * Better encapsulation for TypeVariable.bound * Add support for context-dependent semantics for 'any' type-variables ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.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/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/diags/examples/IllegalRefOnlyCall.java ! test/tools/javac/lib/DPrinter.java + test/tools/javac/valhalla/typespec/TestRefOnly01.java + test/tools/javac/valhalla/typespec/TestRefOnly01.out + test/tools/javac/valhalla/typespec/TestRefOnly02.java + test/tools/javac/valhalla/typespec/TestRefOnly02.out + test/tools/javac/valhalla/typespec/TestRefOnly03.java + test/tools/javac/valhalla/typespec/TestRefOnly03.out + test/tools/javac/valhalla/typespec/TestRefOnly04.java + test/tools/javac/valhalla/typespec/TestRefOnly05.java + test/tools/javac/valhalla/typespec/TestRefOnly06.java + test/tools/javac/valhalla/typespec/items/tests/TestRefOnly.java From ali.ebrahimi1781 at gmail.com Wed Oct 22 20:45:20 2014 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 23 Oct 2014 00:15:20 +0330 Subject: hg: valhalla/valhalla/langtools: Add initial conditional method support: In-Reply-To: <201410221911.s9MJBL4A013465@aojmv0008> References: <201410221911.s9MJBL4A013465@aojmv0008> Message-ID: <CAA0cW5BXqEQrsCPN-oM1YM9P6ToQ4E=yh7V6o4ooDotpGWgr5w@mail.gmail.com> Hi Maurizio, One question: in test method test1 of class TestRefOnly02: class TestRefOnly02 { static abstract class Foo<any T> { abstract __RefOnly void m(); } <any Z> void test1() { new Foo<Z>() { }; <====== }...} This line should not produce compile error: compiler.err.does.not.override.abstract: new Foo<Z>() { }; Since any type var "Z" can also be Ref type. Am I missing some thing here? Is this correct? <any Z> void test1() { new Foo<Z>() { __RefOnly void m(){ } }; } Best Regards, Ali Ebrahimi On Wed, Oct 22, 2014 at 10:41 PM, <maurizio.cimadamore at oracle.com> wrote: > Changeset: 3ffc6541ddba > Author: mcimadamore > Date: 2014-10-22 20:10 +0100 > URL: > http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3ffc6541ddba > > Add initial conditional method support: > * __RefOnly keyword can be used to tag methods that should only be > available on 'erased' receivers > * Better encapsulation for TypeVariable.bound > * Add support for context-dependent semantics for 'any' type-variables > > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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/Enter.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.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/jvm/Gen.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java > + test/tools/javac/diags/examples/IllegalRefOnlyCall.java > ! test/tools/javac/lib/DPrinter.java > + test/tools/javac/valhalla/typespec/TestRefOnly01.java > + test/tools/javac/valhalla/typespec/TestRefOnly01.out > + test/tools/javac/valhalla/typespec/TestRefOnly02.java > + test/tools/javac/valhalla/typespec/TestRefOnly02.out > + test/tools/javac/valhalla/typespec/TestRefOnly03.java > + test/tools/javac/valhalla/typespec/TestRefOnly03.out > + test/tools/javac/valhalla/typespec/TestRefOnly04.java > + test/tools/javac/valhalla/typespec/TestRefOnly05.java > + test/tools/javac/valhalla/typespec/TestRefOnly06.java > + test/tools/javac/valhalla/typespec/items/tests/TestRefOnly.java > > From paul.govereau at oracle.com Wed Oct 22 22:01:33 2014 From: paul.govereau at oracle.com (paul.govereau at oracle.com) Date: Wed, 22 Oct 2014 22:01:33 +0000 Subject: hg: valhalla/valhalla/langtools: Quick and dirty value types. Message-ID: <201410222201.s9MM1YOW014677@aojmv0008> Changeset: 3781712f5f98 Author: pgovereau Date: 2014-10-22 17:59 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3781712f5f98 Quick and dirty value types. * added minimal set of value-type byte codes necessary to represent new operations. * support for javac and javap only. * tried to minimize changes to existing code. ! src/jdk.compiler/share/classes/com/sun/tools/classfile/Descriptor.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/Opcode.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/Signature.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java From maurizio.cimadamore at oracle.com Wed Oct 22 23:02:30 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Oct 2014 00:02:30 +0100 Subject: hg: valhalla/valhalla/langtools: Add initial conditional method support: In-Reply-To: <CAA0cW5BXqEQrsCPN-oM1YM9P6ToQ4E=yh7V6o4ooDotpGWgr5w@mail.gmail.com> References: <201410221911.s9MJBL4A013465@aojmv0008> <CAA0cW5BXqEQrsCPN-oM1YM9P6ToQ4E=yh7V6o4ooDotpGWgr5w@mail.gmail.com> Message-ID: <54483786.8010002@oracle.com> Hi Ali, you are right - this should not compile. My intention was to verify that i.e. 'new Foo<int>' worked, but I agree that it is not sound to allow instantiation _for any Z_. On top of my head, I believe the issue lies in the fact that I shared the same compile-time check for two purposes: 1) verifying that you can actually call a RefOnly method on a receiver T (to check method calls) 2) verifying that a RefOnly method is a member of a given type (for well-formedness check - as in your example) While the check is correct for the first use case, in hindsight, it isn't strict enough for the second; note that, as far as (1) is concerned, in your example m() would _not_ be a callable method for a receiver Foo<any T> (and that's correct - as Foo<any T> can be parameterized with non-reference types); unfortunately, as the logic is reused, this means that javac would also _not_ consider m() to be a member of Foo<any T> - which is why the instantiation goes without errors. Obviously, the two use cases need slightly different logic: in one case you need to prove that at least one parameterization is non-reference to ban a method call; in the other case you have to prove that all instantiations are non-reference to exclude the method from the list of members. We can still share the check - but the routine has to be more clever than it is now :-) Thanks for the prompt report. Maurizio On 22/10/14 21:45, Ali Ebrahimi wrote: > Hi Maurizio, > One question: > in test method test1 of class TestRefOnly02: > > class TestRefOnly02 { > static abstract class Foo<any T> { > abstract __RefOnly void m(); > } > > <any Z> void test1() { > new Foo<Z>() { }; <====== > } > > ... > } > This line should not produce compile error: > compiler.err.does.not.override.abstract: > new Foo<Z>() { }; > > Sinceany type var "Z" canalsobe Ref type. > Am I missing some thing here? > Is this correct? > <any Z> void test1() { > new Foo<Z>() { > __RefOnly void m(){ } > }; > } Yes - I think that should be correct. Maurizio > Best Regards, > Ali Ebrahimi > > On Wed, Oct 22, 2014 at 10:41 PM, <maurizio.cimadamore at oracle.com > <mailto:maurizio.cimadamore at oracle.com>> wrote: > > Changeset: 3ffc6541ddba > Author: mcimadamore > Date: 2014-10-22 20:10 +0100 > URL: > http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3ffc6541ddba > > Add initial conditional method support: > * __RefOnly keyword can be used to tag methods that should only be > available on 'erased' receivers > * Better encapsulation for TypeVariable.bound > * Add support for context-dependent semantics for 'any' type-variables > > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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/Enter.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.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/jvm/Gen.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java > + test/tools/javac/diags/examples/IllegalRefOnlyCall.java > ! test/tools/javac/lib/DPrinter.java > + test/tools/javac/valhalla/typespec/TestRefOnly01.java > + test/tools/javac/valhalla/typespec/TestRefOnly01.out > + test/tools/javac/valhalla/typespec/TestRefOnly02.java > + test/tools/javac/valhalla/typespec/TestRefOnly02.out > + test/tools/javac/valhalla/typespec/TestRefOnly03.java > + test/tools/javac/valhalla/typespec/TestRefOnly03.out > + test/tools/javac/valhalla/typespec/TestRefOnly04.java > + test/tools/javac/valhalla/typespec/TestRefOnly05.java > + test/tools/javac/valhalla/typespec/TestRefOnly06.java > + test/tools/javac/valhalla/typespec/items/tests/TestRefOnly.java > > From maurizio.cimadamore at oracle.com Thu Oct 23 10:41:05 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 23 Oct 2014 10:41:05 +0000 Subject: hg: valhalla/valhalla/langtools: Fix __RefOnly method bug: Message-ID: <201410231041.s9NAf5e6017090@aojmv0008> Changeset: 414758a86208 Author: mcimadamore Date: 2014-10-23 11:37 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/414758a86208 Fix __RefOnly method bug: * Wrong membership test for __RefOnly methods allowed unsound instance creation expressions ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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 ! test/tools/javac/valhalla/typespec/TestRefOnly02.java ! test/tools/javac/valhalla/typespec/TestRefOnly02.out From maurizio.cimadamore at oracle.com Thu Oct 23 13:16:45 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 23 Oct 2014 13:16:45 +0000 Subject: hg: valhalla/valhalla/langtools: Type.isValue should not call flags(): Message-ID: <201410231316.s9NDGj7t013968@aojmv0008> Changeset: 1dcaaaf10826 Author: mcimadamore Date: 2014-10-23 14:13 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/1dcaaaf10826 Type.isValue should not call flags(): * nested classfile completion triggered by recently added isValue() call from Types.typeSig ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java From maurizio.cimadamore at oracle.com Thu Oct 23 14:25:24 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 23 Oct 2014 14:25:24 +0000 Subject: hg: valhalla/valhalla/langtools: Misc ref-only well-formedness fixes: Message-ID: <201410231425.s9NEPPuR023891@aojmv0008> Changeset: 4c4130d5be1f Author: mcimadamore Date: 2014-10-23 15:22 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4c4130d5be1f Misc ref-only well-formedness fixes: * __RefOnly constructor and diamond doesn't work * ban class decls that do not specify at least a constructor for all parameterizations * bad __RefOnly methods from non generic classes ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DoesNotDefineConstr.java + test/tools/javac/diags/examples/IllegalRefOnlyDef.java + test/tools/javac/valhalla/typespec/TestRefOnly07.java + test/tools/javac/valhalla/typespec/TestRefOnly07.out + test/tools/javac/valhalla/typespec/TestRefOnly08.java + test/tools/javac/valhalla/typespec/TestRefOnly08.out From maurizio.cimadamore at oracle.com Fri Oct 24 12:57:32 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 24 Oct 2014 12:57:32 +0000 Subject: hg: valhalla/valhalla/langtools: More ref-only fixes: Message-ID: <201410241257.s9OCvWQd023794@aojmv0008> Changeset: 4e430506203a Author: mcimadamore Date: 2014-10-24 13:56 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4e430506203a More ref-only fixes: * __RefOnly methods cannot mention specializations of same class * override clash check broken for 'any' tvars * generate warnings (instead of errors) for redundant ref-only methods ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties - test/tools/javac/diags/examples/IllegalRefOnlyDef.java + test/tools/javac/diags/examples/RedundantRefOnlyDef.java + test/tools/javac/valhalla/typespec/Clash02.java ! test/tools/javac/valhalla/typespec/TestRefOnly04.java ! test/tools/javac/valhalla/typespec/TestRefOnly08.java ! test/tools/javac/valhalla/typespec/TestRefOnly08.out + test/tools/javac/valhalla/typespec/TestRefOnly09.java From mark.reinhold at oracle.com Fri Oct 24 15:22:44 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 24 Oct 2014 08:22:44 -0700 (PDT) Subject: JEP 218: Generics over Primitive Types Message-ID: <20141024152244.61C783F2C3@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/218 - Mark From maurizio.cimadamore at oracle.com Fri Oct 24 16:18:59 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 24 Oct 2014 16:18:59 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: SpecializeTypes is not setting type-var context when specializing ref-only methods Message-ID: <201410241618.s9OGIxVw029956@aojmv0008> Changeset: d501fa864789 Author: mcimadamore Date: 2014-10-24 17:18 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/d501fa864789 Fix: SpecializeTypes is not setting type-var context when specializing ref-only methods Spourious indified generic calls are emitted in ref-only method context. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! test/tools/javac/valhalla/typespec/items/tests/TestRefOnly.java From simon at ochsenreither.de Sat Oct 25 03:02:09 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Sat, 25 Oct 2014 05:02:09 +0200 Subject: JEP 218: Generics over Primitive Types In-Reply-To: <20141024152244.61C783F2C3@eggemoggin.niobe.net> References: <20141024152244.61C783F2C3@eggemoggin.niobe.net> Message-ID: <544B12B1.2010307@ochsenreither.de> One thing that's still unclear to me is how variance well be handled. In current Java, it would be possible to say "variance is declared at use-site, so we can just reject such variance annotations when the type participating is a value type", but in other languages, this is an issue because of variance is declared at declaration-site. Rejecting all such definitions is a bad idea, because that would mean a large percentage of such types could either not be specialized at all, or wouldn't be able to be variant anymore, including for reference types. Given that even Java has now a JEP Draft? to add declaration-site variance, I think it would be a reasonable idea to figure this out before the issue arises. It would probably make sense to allow such declarations, but specify that all variance relations where a value type participates are collapsed into an invariant definition. It is not an obscure issue: This question arises for popular types like List[T] or Vector[T]. ? http://openjdk.java.net/jeps/8043488 From brian.goetz at oracle.com Sun Oct 26 22:41:49 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 26 Oct 2014 18:41:49 -0400 Subject: JEP 218: Generics over Primitive Types In-Reply-To: <544B12B1.2010307@ochsenreither.de> References: <20141024152244.61C783F2C3@eggemoggin.niobe.net> <544B12B1.2010307@ochsenreither.de> Message-ID: <544D78AD.8080200@oracle.com> We definitely need to address this, and actually quite soon. It is actually much more of an issue for functional interface types (Consumer, Function) than for List or Vector, since both List and Vector have both in- and out- uses of its type arguments, whereas most arguments to functional interfaces do have a natural variance, and properly-written codebases are full of variant uses of these. For example, in Stream, we have to deal with methods like: filter(Predicate<? super T>) The good news is that we've looked at this, and it appears reasonably tractable. We have existing rules for reasoning about wildcards; these are likely to be largely unchanged, and extend naturally to value types as well (with some small adjustments, such as teaching inference that there is no useful variance to be extracted from values during inference.) When we get to the part where we are ready to emit actual classfile signatures, we can reason in parts: - If T is a reference type, we do the same thing we always did. - If T is a value type, then we collapse wildcards to an invariant T. The logic for this is divided across the compiler and the runtime specializer. There are a few small warts here (JLS defines int <: long (in hindsight, this should have been a conversion), but we don't actually want ? extends T to contain "long" when T=int); this is a fairly easily removed wart, since the subtyping is only used in method overload selection, and this can be adjusted to use equivalent conversions. So, yes, we're working on it. On 10/24/2014 11:02 PM, Simon Ochsenreither wrote: > One thing that's still unclear to me is how variance well be handled. > > In current Java, it would be possible to say "variance is declared at > use-site, so we can just reject such variance annotations when the type > participating is a value type", but in other languages, this is an issue > because of variance is declared at declaration-site. > > Rejecting all such definitions is a bad idea, because that would mean a > large percentage of such types could either not be specialized at all, > or wouldn't be able to be variant anymore, including for reference types. > > Given that even Java has now a JEP Draft? to add declaration-site > variance, I think it would be a reasonable idea to figure this out > before the issue arises. > > It would probably make sense to allow such declarations, but specify > that all variance relations where a value type participates are > collapsed into an invariant definition. > > It is not an obscure issue: This question arises for popular types like > List[T] or Vector[T]. > > ? http://openjdk.java.net/jeps/8043488 From simon at ochsenreither.de Mon Oct 27 05:19:11 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Mon, 27 Oct 2014 06:19:11 +0100 Subject: JEP 218: Generics over Primitive Types In-Reply-To: <544D78AD.8080200@oracle.com> References: <20141024152244.61C783F2C3@eggemoggin.niobe.net> <544B12B1.2010307@ochsenreither.de> <544D78AD.8080200@oracle.com> Message-ID: <544DD5CF.9070402@ochsenreither.de> Hi! > - If T is a value type, then we collapse wildcards to an invariant T. Ok, thanks for the clarification. This seems to be exactly what I described earlier. What I'm wondering: For primitive types?e. g. int?it's fairly obvious how to decide whether a user wants variance (by using the reference type, Integer) or a better representation (int), but what's the story here for value types? E. g. is it possible/how would on express: I have an Vector of Value Type, but I want the value Type to be boxed to use the variance of Vector? Thanks, Simon From simon at ochsenreither.de Mon Oct 27 06:21:04 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Mon, 27 Oct 2014 07:21:04 +0100 Subject: Changes to signatures? Message-ID: <544DE450.9080607@ochsenreither.de> Hey everyone! Does anyone know whether Generic Signatures will be updated for JDK 10, or will they stay as-is? Also, one thing that's unclear to me is whether a method like (sorry, I don't speak Java): T[] arrayOf<any T>(int length) { ... } will still emit "Object" as a return type in the signature. I remember that arrays not having a useful common supertype except Object was a pretty ugly thing in the past. Any changes here? Thanks and bye, Simon From brian.goetz at oracle.com Mon Oct 27 13:48:59 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Oct 2014 09:48:59 -0400 Subject: Changes to signatures? In-Reply-To: <544DE450.9080607@ochsenreither.de> References: <544DE450.9080607@ochsenreither.de> Message-ID: <544E4D4B.7050805@oracle.com> > Does anyone know whether Generic Signatures will be updated for JDK 10, > or will they stay as-is? Things that are currently expressible will retain their current expression. There may be new forms of expression added, such as class Foo<any T> { ... } class Foo<ref T> { ... } // existing declarations of Foo<T> // become shorthand for this At the use site, likely no changes. > Also, one thing that's unclear to me is whether a method like (sorry, I > don't speak Java): > > T[] arrayOf<any T>(int length) { ... } That's <any T> T[] arrayOf(int length) { ... } Here, Object comes out in the return type because all array types are objects, including int[]). According to the Value Mantra, which is "What Would int Do", arrays of values would also be objects. So this is (likely) unchanged. Again, because of the desire to allow compatible evolution, changing the erased return type would mean that any-fying an existing generic method would be binary-incompatible, so unless there's a good enough reason here to be willing to take the hit of generating bridges, this is unlikely to change. > will still emit "Object" as a return type in the signature. I remember > that arrays not having a useful common supertype except Object was a > pretty ugly thing in the past. Any changes here? > > Thanks and bye, > > Simon From simon at ochsenreither.de Mon Oct 27 14:55:38 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Mon, 27 Oct 2014 15:55:38 +0100 Subject: Changes to signatures? In-Reply-To: <544E4D4B.7050805@oracle.com> References: <544DE450.9080607@ochsenreither.de> <544E4D4B.7050805@oracle.com> Message-ID: <544E5CEA.8030900@ochsenreither.de> Hi Brian, thanks for the answers! > Things that are currently expressible will retain their current > expression. There may be new forms of expression added, such as > > class Foo<any T> { ... } > class Foo<ref T> { ... } // existing declarations of Foo<T> > // become shorthand for this No, I didn't mean Generics at the language level, but the Generic Signatures emitted in class files. Sorry, if that was not clear. > Here, Object comes out in the return type because all array types are > objects, including int[]). According to the Value Mantra, which is > "What Would int Do", arrays of values would also be objects. So this > is (likely) unchanged. Ok, thanks for the clarification. Bye, Simon From brian.goetz at oracle.com Mon Oct 27 15:24:22 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Oct 2014 11:24:22 -0400 Subject: Changes to signatures? In-Reply-To: <544E5CEA.8030900@ochsenreither.de> References: <544DE450.9080607@ochsenreither.de> <544E4D4B.7050805@oracle.com> <544E5CEA.8030900@ochsenreither.de> Message-ID: <544E63A6.9080403@oracle.com> >> Things that are currently expressible will retain their current >> expression. There may be new forms of expression added, such as >> >> class Foo<any T> { ... } >> class Foo<ref T> { ... } // existing declarations of Foo<T> >> // become shorthand for this > No, I didn't mean Generics at the language level, but the Generic > Signatures emitted in class files. Sorry, if that was not clear. So, at the very least, we have to have a way to encode any-ness (or various other new capabilities or restrictions) of type variables in the classfile. Its possible this will be stuffed into the signature attribute, and also possible we'll add another attribute instead. This is effectively a "syntax" decision that can be late-bound (if in your capacity as compiler-maintainer, you have an opinion, feel free to share.) It's a good time to revisit the generics-related attributes in the class file; one thing that has been a persistent source of pain, that we might fix now, is to have an attribute that encodes metadata about *all* the type variables from enclosing lexical scopes, rather than having to go to N different class files to gather that. (The status quo is OK for compilers, which have probably pulled in the classes anyway, but less OK for a runtime specializer.) The specializer needs this since to transform TT; to something, it has to know what T is being specialized to, and that means it has to know all the tvars in scope, not just the ones declared in the current class/method. From forax at univ-mlv.fr Wed Oct 29 19:05:27 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 29 Oct 2014 20:05:27 +0100 Subject: hg: valhalla/valhalla/jdk: VarHandles for int/long arrays. In-Reply-To: <201410221625.s9MGPkQC014289@aojmv0008> References: <201410221625.s9MGPkQC014289@aojmv0008> Message-ID: <54513A77.3070605@univ-mlv.fr> On 10/22/2014 06:25 PM, paul.sandoz at oracle.com wrote: > Changeset: fff1c746733f > Author: psandoz > Date: 2014-10-22 18:08 +0200 > URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fff1c746733f > > VarHandles for int/long arrays. > > + src/java.base/share/classes/java/lang/invoke/ArrayIntHandle.java > + src/java.base/share/classes/java/lang/invoke/ArrayLongHandle.java > ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > ! src/java.base/share/classes/java/lang/invoke/VarHandles.java > ! test/java/lang/invoke/VarHandleTest.java > Hi Paul, I'm wondering if for any Array*Handle.getVolatile() instead of using unsafe to get the value, it was not better to get the value with an array[index] and use unsafe only to emit the right fence ? cheers, R?mi From paul.sandoz at oracle.com Thu Oct 30 10:18:17 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Oct 2014 11:18:17 +0100 Subject: hg: valhalla/valhalla/jdk: VarHandles for int/long arrays. In-Reply-To: <54513A77.3070605@univ-mlv.fr> References: <201410221625.s9MGPkQC014289@aojmv0008> <54513A77.3070605@univ-mlv.fr> Message-ID: <53594D70-5A4B-4568-81FA-6C1D60086923@oracle.com> Hi Remi, On Oct 29, 2014, at 8:05 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > On 10/22/2014 06:25 PM, paul.sandoz at oracle.com wrote: >> Changeset: fff1c746733f >> Author: psandoz >> Date: 2014-10-22 18:08 +0200 >> URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fff1c746733f >> >> VarHandles for int/long arrays. >> >> + src/java.base/share/classes/java/lang/invoke/ArrayIntHandle.java >> + src/java.base/share/classes/java/lang/invoke/ArrayLongHandle.java >> ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> ! src/java.base/share/classes/java/lang/invoke/VarHandles.java >> ! test/java/lang/invoke/VarHandleTest.java >> > > Hi Paul, > I'm wondering if for any Array*Handle.getVolatile() instead of using unsafe to get the value, > it was not better to get the value with an array[index] and use unsafe only to emit the right fence ? > I think that is possible to do, and should result in better code generation for bounds checks. But, we still have compareAndSet/getAndSet etc. So at the moment i would prefer to leave as is and wait for better optimization of bounds checks (and/or an intrinsic for Integer.compareUnsigned, which could also be useful in nio Buffer implementations): https://bugs.openjdk.java.net/browse/JDK-8042997 https://bugs.openjdk.java.net/browse/JDK-8003585 Paul. From maurizio.cimadamore at oracle.com Thu Oct 30 12:41:21 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 30 Oct 2014 12:41:21 +0000 Subject: hg: valhalla/valhalla/langtools: Fix problems when compiling auxiliary classes: Message-ID: <201410301241.s9UCfMxI013510@aojmv0008> Changeset: 21158ddaed18 Author: mcimadamore Date: 2014-10-30 12:37 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/21158ddaed18 Fix problems when compiling auxiliary classes: * signature attribute of class/field/method shoud not refer to specialized types * moved specialization-related type routines in Types so that they can be shared more easily * refactored main specialization routine to use a type visitor * removed some visitor methods from SpecializeTypes to prevent types from being rewritten in the AST * fixed logic by which StackMapFrame accesses to erased local variable types * added auxiliary class tests ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.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/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java + test/tools/javac/valhalla/typespec/Auxiliary01.java + test/tools/javac/valhalla/typespec/Auxiliary02.java From maurizio.cimadamore at oracle.com Thu Oct 30 12:44:05 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 30 Oct 2014 12:44:05 +0000 Subject: hg: valhalla/valhalla/jdk: Add support to handle primitive types in signature attributes: Message-ID: <201410301244.s9UCi52C014087@aojmv0008> Changeset: b10ab323bbc4 Author: mcimadamore Date: 2014-10-30 12:40 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b10ab323bbc4 Add support to handle primitive types in signature attributes: * Add visitor method for base types to main signature writer subclass * Fix for '>' being consumed too late by the SignatureWriter pipeline * Added tests ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/TypeVariablesMapAttribute.java ! test/valhalla/test/valhalla/specializer/SignatureVisitorTest.java From maurizio.cimadamore at oracle.com Thu Oct 30 13:13:55 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 30 Oct 2014 13:13:55 +0000 Subject: hg: valhalla/valhalla/langtools: Misc cleanup: Message-ID: <201410301313.s9UDDt1C020386@aojmv0008> Changeset: 6329884b7a11 Author: mcimadamore Date: 2014-10-30 13:10 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/6329884b7a11 Misc cleanup: * fixed redundant imports * removed unused field in SpecializeTypes * fixed signature of Items.makeCmpItem ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java From paul.sandoz at oracle.com Thu Oct 30 14:02:06 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Oct 2014 15:02:06 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles Message-ID: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> Hi, I have, with the help of Brian, Doug and John, updated the description of JEP 193: Enhanced Volatiles to reflect our current thinking based on: - the prototype implementation in valhalla; - performance measurements of that implementation; and - investigations related to signature polymorphic methods and invokedynamic. Thanks, Paul. From forax at univ-mlv.fr Thu Oct 30 15:47:25 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 30 Oct 2014 16:47:25 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> Message-ID: <54525D8D.2080801@univ-mlv.fr> On 10/30/2014 03:02 PM, Paul Sandoz wrote: > Hi, > > I have, with the help of Brian, Doug and John, updated the description of JEP 193: Enhanced Volatiles to reflect our current thinking based on: > > - the prototype implementation in valhalla; > - performance measurements of that implementation; and > - investigations related to signature polymorphic methods and invokedynamic. > > Thanks, > Paul. I seems that the changes are not propagated to the JEP yet, but there are available throught the corresponding bug: https://bugs.openjdk.java.net/browse/JDK-8046183 cheers, R?mi From paul.sandoz at oracle.com Thu Oct 30 15:53:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Oct 2014 16:53:23 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <54525D8D.2080801@univ-mlv.fr> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> Message-ID: <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > On 10/30/2014 03:02 PM, Paul Sandoz wrote: >> Hi, >> >> I have, with the help of Brian, Doug and John, updated the description of JEP 193: Enhanced Volatiles to reflect our current thinking based on: >> >> - the prototype implementation in valhalla; >> - performance measurements of that implementation; and >> - investigations related to signature polymorphic methods and invokedynamic. >> >> Thanks, >> Paul. > > I seems that the changes are not propagated to the JEP yet, > but there are available throught the corresponding bug: > https://bugs.openjdk.java.net/browse/JDK-8046183 > Doh! thanks, i forgot to send the link out, Paul, From Jonathan.Ross at imc-chicago.com Thu Oct 30 16:43:24 2014 From: Jonathan.Ross at imc-chicago.com (Jonathan C. Ross) Date: Thu, 30 Oct 2014 11:43:24 -0500 Subject: An alternative to explicit template specialization: explicit versioning Message-ID: <ABCE1890-6FCF-41B8-A7C4-B6D3768275FF@imc-chicago.com> Hi all, Regarding the discussion on explicit template specialization, I find myself to be in the all-or-nothing camp: either we introduce the general mechanism, or we don?t expose any explicit form to the end user. Assuming that the project is not aiming to redo generics and introduce language support for specializing templates for arbitrary types, I find myself wondering whether there are in fact any compelling usecases for exposing template specialization to java programmers, and not to do our upmost best to keep it hidden? The only reason I can come up with (and the example discussed in the state of the specialization document) is the usual one: preserving backwards compatibility. Assuming that the motivation is indeed primarily the preservation of backwards compatibility, has anyone explored any other mechanisms for doing that? One possibility mechanism might be a beefed-up, explicit deprecation mechanism that couples the visibility of methods to the class file version of the client code. (Dr. Deprecation - Stuart Marks - might like this. It could be used as a mechanism for actually removing code that was marked deprecated in previous versions of the JVM.) So, taking the example from the state of the specialization document: interface ListLike<T> { @Removed(?1.9?) // pay no attention to exact syntax void remove(int i); @Removed(?1.9") void remove(T t); @New(1.9") // maybe implied by overloading the previous declaration? void remove(T t); void removeByIndex(); } The methods annotated @Removed(?1.9?), would only be visible to classes with class version 34 or lower, the methods annotated with @New(?1.9?) only from 35 and up. (Please don?t pay any attention to syntax, or indeed whether we will get this shipped with 1.9...) This mechanism should be easy enough to extend to classes and member variables too. It would also be applicable to any other project where one would rather redesign the API. From my perspective as a developer, it would be more intuitive than the template specialization alternative presented in the ?state of the specialization? document. The mechanism would allow library developers to ship class files that would support different multiple versions of the JVM at once, or they could focus on just a single JVM if they wanted. If I want to implement ListLike<T> for just 1.9 and up in the example above, I only have to implement two methods from the interface; same if I want to stick to 1.8 and below. IDEs could help a hand by (optionally) only showing available API?s, in particular when offering autocomplete suggestions. I am no byte code or class file layout expert, but I am sure it would be possible to implement this idea using attributes that mirror the Removed/New annotations. Perhaps having multiple versions of methods/fields/classes with exactly the same signature, differing only by the supported class file versions (like in the example above) would be a tougher nut to crack, but I would imagine that it would be a usable mechanism even with the constraint in place that one cannot replace a method/class/field with exactly the same signature. As an ?end user?, I would find it more appealing and intuitive to work with versioned API?s than with the - for any given JDK version - much larger API that would be required to retrofit API?s to work for <any T>. As a stakeholder in the further development of the Java programming language, I would be excited by a mechanism that would allow JDK engineers to throw out the old, and be able to innovate without worrying about breaking existing code. Thoughts? Jonathan Ross ________________________________ The information in this e-mail is intended only for the person or entity to which it is addressed. It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it. If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments. Messages and attachments are scanned for all known viruses. Always scan attachments before opening them. From maurizio.cimadamore at oracle.com Thu Oct 30 16:52:10 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 30 Oct 2014 16:52:10 +0000 Subject: hg: valhalla/valhalla/langtools: Specialized LDC broken after recent changes. Message-ID: <201410301652.s9UGqA5L029526@aojmv0008> Changeset: 3cab1ef8e868 Author: mcimadamore Date: 2014-10-30 16:51 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3cab1ef8e868 Specialized LDC broken after recent changes. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java From paul.sandoz at oracle.com Thu Oct 30 17:09:04 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Oct 2014 18:09:04 +0100 Subject: [jmm-dev] Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <54526610.1030805@redhat.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54526610.1030805@redhat.com> Message-ID: <B7E36F5A-9171-4D3F-B176-B5123E68037F@oracle.com> [switching from jmm-dev to valhall-dev] On Oct 30, 2014, at 5:23 PM, "David M. Lloyd" <david.lloyd at redhat.com> wrote: > On 10/30/2014 10:53 AM, Paul Sandoz wrote: >> >> On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: >> >>> >>> On 10/30/2014 03:02 PM, Paul Sandoz wrote: >>>> Hi, >>>> >>>> I have, with the help of Brian, Doug and John, updated the description of JEP 193: Enhanced Volatiles to reflect our current thinking based on: >>>> >>>> - the prototype implementation in valhalla; >>>> - performance measurements of that implementation; and >>>> - investigations related to signature polymorphic methods and invokedynamic. >>>> >>>> Thanks, >>>> Paul. >>> >>> I seems that the changes are not propagated to the JEP yet, >>> but there are available throught the corresponding bug: >>> https://bugs.openjdk.java.net/browse/JDK-8046183 >>> >> >> Doh! thanks, i forgot to send the link out, > > Wow, that's even *more* convoluted. Are we *certain* that we are actually improving on the original proposal here? It seems to me like everyone can't jump on the *handle bandwagon fast enough, even though it seems to be objectively more complex from concept (that human engineers want to understand) to API (the previously proposed API was very much cleaner and didn't rely on cross-your-fingers magic to make inefficient things become efficient) to implementation (to this day, relatively few people outside of Oracle even have a glimmer of understanding as to the rules and behaviors of these things). > The original JEP did not talk much about how javac would translate a "floating" invocation on a type specific interface to byte code. Our thinking was to use the same mechanisms as in the updated JEP and the "cross-your-fingers magic " you refer to, which on investigation has actually proven to be quite reliable (the goats are safe!). > Are we *certain* this is an improvement? > Yes, it's an improvement on Unsafe and i think we can incrementally improve it over time without needing to introduce a special syntax. Paul. From brian.goetz at oracle.com Thu Oct 30 17:41:50 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 30 Oct 2014 13:41:50 -0400 Subject: An alternative to explicit template specialization: explicit versioning In-Reply-To: <ABCE1890-6FCF-41B8-A7C4-B6D3768275FF@imc-chicago.com> References: <ABCE1890-6FCF-41B8-A7C4-B6D3768275FF@imc-chicago.com> Message-ID: <5452785E.9080506@oracle.com> Hi Jonathan; I totally understand your reaction of "why does any of this have to be explicit, wouldn't it be great if it could be implicit?" First, let me reassure you that we have the same concerns. *OF COURSE* it would be nicer if you could magically take existing generics and extend the domain of their type arguments to include primitives and values. If we could, we would. And maybe we'll be able to; right now, we don't see a way to do that without introducing worse complexity, but we're just getting started on a long road and I predict that almost everything that we've got on the table now will have changed in some way by the time we're done. There's quite a tangle of issues here, so let me try to quickly untangle some of them. - The goal of the project is to have efficient generics over primitives and values. (If we didn't care about efficiency, we'd already be done; generics over boxed primitives are acceptably expressive now, and do not have these corner cases we're concerned about.) - The migration potholes like remove(T)/remove(int) are just that -- migration potholes. They will need to be paved over. If we can do so compatibly without introducing language features, so much the better; I am no fan of the complexity of conditional methods, nor do I like the idea of adding language features that we hope will be very infrequently used. So we're looking for the minimal-complexity way to pave over these potholes in a responsible way. - We did explore an explicit versioning approach in the early days of default methods. Once you take into account all the real requirements, including separate compilation and version skew between compiler and runtime, this gets quite complex indeed, and we abandoned this direction as being more complexity than was needed to address the real goal -- which was interface evolution. I can't say for sure whether we'd reach the same conclusion with respect to the current problem, but it seems kind of likely. - There are places where user control over specialization is in fact a positive thing. In our discussions with .NET users, for example, we found a significant pain point with their generics was that it was impossible to provide a different implementation for foo() in Foo<T> based on whether the receiver had T as a reference or value type. Auto-specialization is nice, but I can imagine a better implementation of ArrayList<boolean> than the obvious specialization, and it might be nice to let API implementors do so in a way that's transparent to users. Etc etc. I do think your assumption that the complexity of fine-grained versioning is less than that of specialization is not likely to survive deep exploration; I think its one of those situations where its easy to write the easy cases on the board and conclude its easy enough, and still be several PhD theses away from a good answer. We're just farther along in the specialization analysis so the warts of that approach are more evident than the warts of a less-explored approach. I do sympathize with your "why should the user even have to know about this" reaction; we hope we can lower the maintenance burden. Right now, though, we're a long way from making any of those decisions -- we're mostly trying to figure out if and how the approach works. Cheers, -Brian On 10/30/2014 12:43 PM, Jonathan C. Ross wrote: > Hi all, > > Regarding the discussion on explicit template specialization, I find myself to be in the all-or-nothing camp: either we introduce the general mechanism, or we don?t expose any explicit form to the end user. > > Assuming that the project is not aiming to redo generics and introduce language support for specializing templates for arbitrary types, I find myself wondering whether there are in fact any compelling usecases for exposing template specialization to java programmers, and not to do our upmost best to keep it hidden? The only reason I can come up with (and the example discussed in the state of the specialization document) is the usual one: preserving backwards compatibility. Assuming that the motivation is indeed primarily the preservation of backwards compatibility, has anyone explored any other mechanisms for doing that? > > One possibility mechanism might be a beefed-up, explicit deprecation mechanism that couples the visibility of methods to the class file version of the client code. (Dr. Deprecation - Stuart Marks - might like this. It could be used as a mechanism for actually removing code that was marked deprecated in previous versions of the JVM.) So, taking the example from the state of the specialization document: > > interface ListLike<T> { > @Removed(?1.9?) // pay no attention to exact syntax > void remove(int i); > @Removed(?1.9") > void remove(T t); > > @New(1.9") // maybe implied by overloading the previous declaration? > void remove(T t); > void removeByIndex(); > } > > The methods annotated @Removed(?1.9?), would only be visible to classes with class version 34 or lower, the methods annotated with @New(?1.9?) only from 35 and up. (Please don?t pay any attention to syntax, or indeed whether we will get this shipped with 1.9...) This mechanism should be easy enough to extend to classes and member variables too. It would also be applicable to any other project where one would rather redesign the API. From my perspective as a developer, it would be more intuitive than the template specialization alternative presented in the ?state of the specialization? document. > > The mechanism would allow library developers to ship class files that would support different multiple versions of the JVM at once, or they could focus on just a single JVM if they wanted. If I want to implement ListLike<T> for just 1.9 and up in the example above, I only have to implement two methods from the interface; same if I want to stick to 1.8 and below. IDEs could help a hand by (optionally) only showing available API?s, in particular when offering autocomplete suggestions. > > I am no byte code or class file layout expert, but I am sure it would be possible to implement this idea using attributes that mirror the Removed/New annotations. Perhaps having multiple versions of methods/fields/classes with exactly the same signature, differing only by the supported class file versions (like in the example above) would be a tougher nut to crack, but I would imagine that it would be a usable mechanism even with the constraint in place that one cannot replace a method/class/field with exactly the same signature. > > As an ?end user?, I would find it more appealing and intuitive to work with versioned API?s than with the - for any given JDK version - much larger API that would be required to retrofit API?s to work for <any T>. As a stakeholder in the further development of the Java programming language, I would be excited by a mechanism that would allow JDK engineers to throw out the old, and be able to innovate without worrying about breaking existing code. > > Thoughts? > > Jonathan Ross > > > ________________________________ > > The information in this e-mail is intended only for the person or entity to which it is addressed. > > It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it. > > If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments. > > Messages and attachments are scanned for all known viruses. Always scan attachments before opening them. > From maurizio.cimadamore at oracle.com Thu Oct 30 18:59:10 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 30 Oct 2014 18:59:10 +0000 Subject: hg: valhalla/valhalla/langtools: ByetcodeMapping signatures should not mention specialized classes: Message-ID: <201410301859.s9UIxAh8021498@aojmv0008> Changeset: c5a78484f13e Author: mcimadamore Date: 2014-10-30 18:55 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c5a78484f13e ByetcodeMapping signatures should not mention specialized classes: * Add unspecializtion routine in Types * Better separation of roles between SpecializeTypes and TransTypes * Fixed signature tests ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/IndifierTranslator.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! test/tools/javac/valhalla/typespec/items/tests/TestIndy.java ! test/tools/javac/valhalla/typespec/items/tests/TestRespecialization.java From forax at univ-mlv.fr Thu Oct 30 19:58:12 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 30 Oct 2014 20:58:12 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> Message-ID: <54529854.2090608@univ-mlv.fr> On 10/30/2014 04:53 PM, Paul Sandoz wrote: > On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: > >> On 10/30/2014 03:02 PM, Paul Sandoz wrote: >>> Hi, >>> >>> I have, with the help of Brian, Doug and John, updated the description of JEP 193: Enhanced Volatiles to reflect our current thinking based on: >>> >>> - the prototype implementation in valhalla; >>> - performance measurements of that implementation; and >>> - investigations related to signature polymorphic methods and invokedynamic. >>> >>> Thanks, >>> Paul. >> I seems that the changes are not propagated to the JEP yet, >> but there are available throught the corresponding bug: >> https://bugs.openjdk.java.net/browse/JDK-8046183 >> > Doh! thanks, i forgot to send the link out, > Paul, Here is a kind of counter-proposal because I think that there is a far simpler and more secure API. I think that instead of having to first instantiate an object (VarHandle) and then call a method on it, this can be done in one method. |public class Safe { @Intrinsic public staticObject get(Object receiver, String fieldName) { }| || @Intrinsic public staticObject getRelaxed(Object receiver, String fieldName) { }| ||||@Intrinsic|| ||||public staticObject getAcquire(Object receiver, String fieldName) { }||| |||||| @Intrinsic||| ||||public staticObject getRelaxed(Object receiver, String fieldName) { }||| ||||| @Intrinsic|||| ||||public staticObject |||||||getSequential|(Object receiver, String fieldName) { }|| | |||||| @Intrinsic||||| |||public static void set(|||||||Object receiver, String fieldName|||, Object value) { }| // and all other related variations ... }| and this is how to use it: class Foo { | int i; public void acquire() { |||boolean r= (boolean)Safe.compareAndSet(this, "i", 0, 1); ... | } }| At compile time, the compiler checks that a method Safe.compareAndSet with compatible parameter types exists but instead of generating an invokestatic, it generates an invokedynamic which uses the signature of the actual callsite. Using the actual types in the signature allows to avoid unnecessary boxing while keeping the typechecking rules simples (they are not changed !) as explained in the current draft of JEP 193. This API doesn't use any object to represent a field but uses a String as field name, you may think that 1) this mean that the field will be queried each time: It doesn't has to. invokedynamic allow to install a dynamic check that will test that the string doesn't change from one call to another. This check will be removed by the JIT because the string never change (if the string change, the best is to throw a runtime exception like IllegalArgumentException explaining that the field name must be a constant). 2) that using a String is not typesafe. Having a typesafe API is hard here, because the type of a field is not something you can get at compile time, there is no field reference syntax in Java (no Foo::i), so a String seems to be a good practical choice. And this API has a true real advantage compared to the VarHandle API, this API is inherently more secure. A VarHandle or any object representing a field will have some special security credential because it can access to a field without having to check at runtime if the field is visible from where the call is done (for performance reason). From my own experience, it's too easy to make this kind of object too visible introduced a security hole without even doing something hard. By not reifying the access to a field as an object, the API is more secure with the restriction that a method can only access to the field of the class that contains the call to the API. In term of implementation, the compiler will generate this bytecode for the class Foo: ||class Foo { | int i; public void acquire() { invokedynamic "compareAndSet" (Foo;String;II)Z BSM =||java.lang.invoke.SafeMetaProtocol|||.bootstrap(Lookup;String;MethodType;MethodHandle) ARG = MH(||||||Safe.compareAndSet(||Object;String;Object;Object;) istore 0|||| ... | } }| and from the JLS perspective, the compiler will recognize that the method inside Safe are special because there are annotated by an annotation that has a meta-annotation named BootstrapMethod that specifies the bootstrap method that should be used when emitting the invokedynamic call. |||| @BootstrapMethod(type=java.lang.invoke.SafeMetaProtocol.class, name="bootstrap") @interface Intrinsic { // empty } cheers, R?mi From forax at univ-mlv.fr Thu Oct 30 20:12:19 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 30 Oct 2014 21:12:19 +0100 Subject: hg: valhalla/valhalla/jdk: VarHandles for int/long arrays. In-Reply-To: <53594D70-5A4B-4568-81FA-6C1D60086923@oracle.com> References: <201410221625.s9MGPkQC014289@aojmv0008> <54513A77.3070605@univ-mlv.fr> <53594D70-5A4B-4568-81FA-6C1D60086923@oracle.com> Message-ID: <54529BA3.5070105@univ-mlv.fr> On 10/30/2014 11:18 AM, Paul Sandoz wrote: > Hi Remi, > > On Oct 29, 2014, at 8:05 PM, Remi Forax <forax at univ-mlv.fr> wrote: >> On 10/22/2014 06:25 PM, paul.sandoz at oracle.com wrote: >>> Changeset: fff1c746733f >>> Author: psandoz >>> Date: 2014-10-22 18:08 +0200 >>> URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fff1c746733f >>> >>> VarHandles for int/long arrays. >>> >>> + src/java.base/share/classes/java/lang/invoke/ArrayIntHandle.java >>> + src/java.base/share/classes/java/lang/invoke/ArrayLongHandle.java >>> ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >>> ! src/java.base/share/classes/java/lang/invoke/VarHandles.java >>> ! test/java/lang/invoke/VarHandleTest.java >>> >> Hi Paul, >> I'm wondering if for any Array*Handle.getVolatile() instead of using unsafe to get the value, >> it was not better to get the value with an array[index] and use unsafe only to emit the right fence ? >> > I think that is possible to do, and should result in better code generation for bounds checks. and also better code generation by example when multiple writes are done on the same field. > But, we still have compareAndSet/getAndSet etc. yes, anyway if at the end only compareAndSet, getAndAdd stay as unsafe intrinsics, I will call it a big achievement. > > So at the moment i would prefer to leave as is and wait for better optimization of bounds checks (and/or an intrinsic for Integer.compareUnsigned, which could also be useful in nio Buffer implementations): > > https://bugs.openjdk.java.net/browse/JDK-8042997 > https://bugs.openjdk.java.net/browse/JDK-8003585 While these bugs need to be fixed, using fences can also provide an interesting point of comparison. > > Paul. > > R?mi From georges.gomes at gmail.com Thu Oct 30 20:37:43 2014 From: georges.gomes at gmail.com (Georges Gomes) Date: Thu, 30 Oct 2014 20:37:43 +0000 Subject: Update to description of JEP 193: Enhanced Volatiles References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> Message-ID: <CAKOqNJ-g6mGAmz+vaomt1N3Z4y8Wvr-4CTSKO02UGfGCHvuaXA@mail.gmail.com> Hi Paul This looks really good this way. IMHO much better than previous proposal. My only concern would be around refactorings. I guess it's only an IDE problem... But it needs to be manageable by IDE. In that sense, Remy's proposal is slightly easier to manage by the IDEs no? Regards Georges On Thu Oct 30 2014 at 8:59:13 PM Remi Forax <forax at univ-mlv.fr> wrote: > > On 10/30/2014 04:53 PM, Paul Sandoz wrote: > > On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > > >> On 10/30/2014 03:02 PM, Paul Sandoz wrote: > >>> Hi, > >>> > >>> I have, with the help of Brian, Doug and John, updated the description > of JEP 193: Enhanced Volatiles to reflect our current thinking based on: > >>> > >>> - the prototype implementation in valhalla; > >>> - performance measurements of that implementation; and > >>> - investigations related to signature polymorphic methods and > invokedynamic. > >>> > >>> Thanks, > >>> Paul. > >> I seems that the changes are not propagated to the JEP yet, > >> but there are available throught the corresponding bug: > >> https://bugs.openjdk.java.net/browse/JDK-8046183 > >> > > Doh! thanks, i forgot to send the link out, > > Paul, > > Here is a kind of counter-proposal because I think that there is a far > simpler and more secure API. > > I think that instead of having to first instantiate an object > (VarHandle) and then call a method on it, > this can be done in one method. > > |public class Safe { > @Intrinsic > public staticObject get(Object receiver, String fieldName) { }| > || @Intrinsic > public staticObject getRelaxed(Object receiver, String fieldName) > { }| > ||||@Intrinsic|| > ||||public staticObject getAcquire(Object receiver, String > fieldName) { }||| > |||||| @Intrinsic||| > ||||public staticObject getRelaxed(Object receiver, String > fieldName) { }||| > ||||| @Intrinsic|||| > ||||public staticObject |||||||getSequential|(Object receiver, > String fieldName) { }|| > | > |||||| @Intrinsic||||| > |||public static void set(|||||||Object receiver, String > fieldName|||, Object value) { }| > // and all other related variations > > ... > }| > > and this is how to use it: > > class Foo { > > | int i; > > public void acquire() { > |||boolean r= (boolean)Safe.compareAndSet(this, "i", 0, 1); > ... > | } > }| > > > At compile time, the compiler checks that a method Safe.compareAndSet > with compatible parameter types exists > but instead of generating an invokestatic, it generates an invokedynamic > which uses the signature of the actual callsite. > Using the actual types in the signature allows to avoid unnecessary > boxing while > keeping the typechecking rules simples (they are not changed !) as > explained in the current draft of JEP 193. > > This API doesn't use any object to represent a field but uses a String > as field name, you may think that > 1) this mean that the field will be queried each time: > It doesn't has to. invokedynamic allow to install a dynamic check > that will test that the string doesn't change > from one call to another. This check will be removed by the JIT > because the string never change > (if the string change, the best is to throw a runtime exception > like IllegalArgumentException explaining > that the field name must be a constant). > 2) that using a String is not typesafe. Having a typesafe API is hard > here, because the type of a field > is not something you can get at compile time, there is no field > reference syntax in Java (no Foo::i), > so a String seems to be a good practical choice. > > And this API has a true real advantage compared to the VarHandle API, > this API is inherently more secure. > A VarHandle or any object representing a field will have some special > security credential because it can access > to a field without having to check at runtime if the field is visible > from where the call is done (for performance reason). > From my own experience, it's too easy to make this kind of object too > visible introduced a security hole without > even doing something hard. > By not reifying the access to a field as an object, the API is more > secure with the restriction > that a method can only access to the field of the class that contains > the call to the API. > > In term of implementation, the compiler will generate this bytecode for > the class Foo: > > ||class Foo { > > | int i; > > public void acquire() { > invokedynamic "compareAndSet" (Foo;String;II)Z > BSM =||java.lang.invoke.SafeMetaProtocol|||.bootstrap( > Lookup;String;MethodType;MethodHandle) > ARG = MH(||||||Safe.compareAndSet(||Object;String;Object;Object;) > istore 0|||| > ... > | } > }| > > and from the JLS perspective, the compiler will recognize that the > method inside Safe > are special because there are annotated by an annotation that has a > meta-annotation > named BootstrapMethod that specifies the bootstrap method that should be > used > when emitting the invokedynamic call. > > |||| > > @BootstrapMethod(type=java.lang.invoke.SafeMetaProtocol.class, > name="bootstrap") > @interface Intrinsic { > // empty > } > > cheers, > R?mi > > From paul.sandoz at oracle.com Fri Oct 31 13:37:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Oct 2014 14:37:26 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <54529854.2090608@univ-mlv.fr> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> Message-ID: <7342F03D-62A0-4750-9D2C-11082D3A751C@oracle.com> Hi Remi, Thanks, that's an interesting approach which has not previously occurred to me. So this proposal combines lookup and access into one call. IIUC to do that effectively the dynamic call site needs to initially provide a "slow" MH that performs an access-control-check, and then updates the call site (once only) with a MH performing the faster check that assumes the field identifier is held constant (and if not barfs). I find the use of the String a little raw, it does not uniquely identify a field, unless there is more information encoded, and is error prone when repeatedly declared. There is one less possible runtime exception for arity but that is counter balanced with one each for access control and constant-check per call-site. If we could introduce a more formal field identifier it would strengthen the proposal. So i think it worth keeping this idea around while seeing how we progress with handles and especially generic handles. We could perform similar checks on VarHandle invocation too with a dynamic call site, if such integrity [1] is a concern. For non-public fields, the slow path checks that the lookup class has access to the receiver class before proceeding [2], although that would then differentiate from MH behaviour. It could even be configured as something optional, or even perhaps programatically "these are the set of classes i give access permission". An obvious observation: existing Unsafe or Atomic*Update refs need to be guarded from leakage, so this pattern is not new or unexpected. When converting Unsafe usages to VarHandle it's quite simple to maintain that pattern. Further, it's possible have tooling that detect such leaks. Paul. [1] I am more concerned about integrity ("private" means private etc.) rather than security with a security manager. [2] Can such checks be folded away? On Oct 30, 2014, at 8:58 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > On 10/30/2014 04:53 PM, Paul Sandoz wrote: >> On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: >> >>> On 10/30/2014 03:02 PM, Paul Sandoz wrote: >>>> Hi, >>>> >>>> I have, with the help of Brian, Doug and John, updated the description of JEP 193: Enhanced Volatiles to reflect our current thinking based on: >>>> >>>> - the prototype implementation in valhalla; >>>> - performance measurements of that implementation; and >>>> - investigations related to signature polymorphic methods and invokedynamic. >>>> >>>> Thanks, >>>> Paul. >>> I seems that the changes are not propagated to the JEP yet, >>> but there are available throught the corresponding bug: >>> https://bugs.openjdk.java.net/browse/JDK-8046183 >>> >> Doh! thanks, i forgot to send the link out, >> Paul, > > Here is a kind of counter-proposal because I think that there is a far simpler and more secure API. > > I think that instead of having to first instantiate an object (VarHandle) and then call a method on it, > this can be done in one method. > > |public class Safe { > @Intrinsic > public staticObject get(Object receiver, String fieldName) { }| > || @Intrinsic > public staticObject getRelaxed(Object receiver, String fieldName) { }| > ||||@Intrinsic|| > ||||public staticObject getAcquire(Object receiver, String fieldName) { }||| > |||||| @Intrinsic||| > ||||public staticObject getRelaxed(Object receiver, String fieldName) { }||| > ||||| @Intrinsic|||| > ||||public staticObject |||||||getSequential|(Object receiver, String fieldName) { }|| > | > |||||| @Intrinsic||||| > |||public static void set(|||||||Object receiver, String fieldName|||, Object value) { }| > // and all other related variations > ... }| > > and this is how to use it: > > class Foo { > > | int i; > > public void acquire() { > |||boolean r= (boolean)Safe.compareAndSet(this, "i", 0, 1); > ... > | } > }| > > > At compile time, the compiler checks that a method Safe.compareAndSet with compatible parameter types exists > but instead of generating an invokestatic, it generates an invokedynamic which uses the signature of the actual callsite. > Using the actual types in the signature allows to avoid unnecessary boxing while > keeping the typechecking rules simples (they are not changed !) as explained in the current draft of JEP 193. > > This API doesn't use any object to represent a field but uses a String as field name, you may think that > 1) this mean that the field will be queried each time: > It doesn't has to. invokedynamic allow to install a dynamic check that will test that the string doesn't change > from one call to another. This check will be removed by the JIT because the string never change > (if the string change, the best is to throw a runtime exception like IllegalArgumentException explaining > that the field name must be a constant). > 2) that using a String is not typesafe. Having a typesafe API is hard here, because the type of a field > is not something you can get at compile time, there is no field reference syntax in Java (no Foo::i), > so a String seems to be a good practical choice. > > And this API has a true real advantage compared to the VarHandle API, this API is inherently more secure. > A VarHandle or any object representing a field will have some special security credential because it can access > to a field without having to check at runtime if the field is visible from where the call is done (for performance reason). > From my own experience, it's too easy to make this kind of object too visible introduced a security hole without > even doing something hard. > By not reifying the access to a field as an object, the API is more secure with the restriction > that a method can only access to the field of the class that contains the call to the API. > > In term of implementation, the compiler will generate this bytecode for the class Foo: > > ||class Foo { > > | int i; > > public void acquire() { > invokedynamic "compareAndSet" (Foo;String;II)Z > BSM =||java.lang.invoke.SafeMetaProtocol|||.bootstrap(Lookup;String;MethodType;MethodHandle) > ARG = MH(||||||Safe.compareAndSet(||Object;String;Object;Object;) > istore 0|||| > ... > | } > }| > > and from the JLS perspective, the compiler will recognize that the method inside Safe > are special because there are annotated by an annotation that has a meta-annotation > named BootstrapMethod that specifies the bootstrap method that should be used > when emitting the invokedynamic call. > > |||| > > @BootstrapMethod(type=java.lang.invoke.SafeMetaProtocol.class, name="bootstrap") > @interface Intrinsic { > // empty > } > > cheers, > R?mi > From paul.sandoz at oracle.com Fri Oct 31 13:52:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Oct 2014 14:52:10 +0100 Subject: hg: valhalla/valhalla/jdk: VarHandles for int/long arrays. In-Reply-To: <54529BA3.5070105@univ-mlv.fr> References: <201410221625.s9MGPkQC014289@aojmv0008> <54513A77.3070605@univ-mlv.fr> <53594D70-5A4B-4568-81FA-6C1D60086923@oracle.com> <54529BA3.5070105@univ-mlv.fr> Message-ID: <0BAABB95-5A68-4D8E-8B61-1589B95DD899@oracle.com> On Oct 30, 2014, at 9:12 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > On 10/30/2014 11:18 AM, Paul Sandoz wrote: >> Hi Remi, >> >> On Oct 29, 2014, at 8:05 PM, Remi Forax <forax at univ-mlv.fr> wrote: >>> On 10/22/2014 06:25 PM, paul.sandoz at oracle.com wrote: >>>> Changeset: fff1c746733f >>>> Author: psandoz >>>> Date: 2014-10-22 18:08 +0200 >>>> URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fff1c746733f >>>> >>>> VarHandles for int/long arrays. >>>> >>>> + src/java.base/share/classes/java/lang/invoke/ArrayIntHandle.java >>>> + src/java.base/share/classes/java/lang/invoke/ArrayLongHandle.java >>>> ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >>>> ! src/java.base/share/classes/java/lang/invoke/VarHandles.java >>>> ! test/java/lang/invoke/VarHandleTest.java >>>> >>> Hi Paul, >>> I'm wondering if for any Array*Handle.getVolatile() instead of using unsafe to get the value, >>> it was not better to get the value with an array[index] and use unsafe only to emit the right fence ? >>> >> I think that is possible to do, and should result in better code generation for bounds checks. > > and also better code generation by example when multiple writes are done on the same field. > Perhaps, i would need to experiment with fences + aastore/load vs. Unsafe. >> But, we still have compareAndSet/getAndSet etc. > > yes, anyway if at the end only compareAndSet, getAndAdd stay as unsafe intrinsics, I will call it a big achievement. > There is an edge case where we may still need to consistently use Unsafe, specifically for long values and platforms that do not support 64-bit CAS, see: https://bugs.openjdk.java.net/browse/JDK-8044616 Paul. From duncan.macgregor at ge.com Fri Oct 31 13:57:10 2014 From: duncan.macgregor at ge.com (MacGregor, Duncan (GE Energy Management)) Date: Fri, 31 Oct 2014 13:57:10 +0000 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <7342F03D-62A0-4750-9D2C-11082D3A751C@oracle.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> <7342F03D-62A0-4750-9D2C-11082D3A751C@oracle.com> Message-ID: <D07942CA.BED39%duncan.macgregor@ge.com> I like the overall idea but also think the string feels wrong, it suggests that both the class of the object and the field name could be dynamic and might change with every invocation, but I really doubt we?d want that. If we were to approach this from the callsite point of view then the type of the site should specify the class which owns the field and the type of that field, with the name specified by the String passed to the bsm, and the Java syntax would have to make it obvious that those are not dynamically changeable. How would we express operations on atomic fields with this scheme? Regards, Duncan. On 31/10/2014 13:37, "Paul Sandoz" <paul.sandoz at oracle.com> wrote: >Hi Remi, > >Thanks, that's an interesting approach which has not previously occurred >to me. > >So this proposal combines lookup and access into one call. IIUC to do >that effectively the dynamic call site needs to initially provide a >"slow" MH that performs an access-control-check, and then updates the >call site (once only) with a MH performing the faster check that assumes >the field identifier is held constant (and if not barfs). > >I find the use of the String a little raw, it does not uniquely identify >a field, unless there is more information encoded, and is error prone >when repeatedly declared. There is one less possible runtime exception >for arity but that is counter balanced with one each for access control >and constant-check per call-site. > >If we could introduce a more formal field identifier it would strengthen >the proposal. So i think it worth keeping this idea around while seeing >how we progress with handles and especially generic handles. > > >We could perform similar checks on VarHandle invocation too with a >dynamic call site, if such integrity [1] is a concern. For non-public >fields, the slow path checks that the lookup class has access to the >receiver class before proceeding [2], although that would then >differentiate from MH behaviour. It could even be configured as something >optional, or even perhaps programatically "these are the set of classes i >give access permission". > >An obvious observation: existing Unsafe or Atomic*Update refs need to be >guarded from leakage, so this pattern is not new or unexpected. When >converting Unsafe usages to VarHandle it's quite simple to maintain that >pattern. Further, it's possible have tooling that detect such leaks. > >Paul. > >[1] I am more concerned about integrity ("private" means private etc.) >rather than security with a security manager. > >[2] Can such checks be folded away? > > >On Oct 30, 2014, at 8:58 PM, Remi Forax <forax at univ-mlv.fr> wrote: > >> >> On 10/30/2014 04:53 PM, Paul Sandoz wrote: >>> On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: >>> >>>> On 10/30/2014 03:02 PM, Paul Sandoz wrote: >>>>> Hi, >>>>> >>>>> I have, with the help of Brian, Doug and John, updated the >>>>>description of JEP 193: Enhanced Volatiles to reflect our current >>>>>thinking based on: >>>>> >>>>> - the prototype implementation in valhalla; >>>>> - performance measurements of that implementation; and >>>>> - investigations related to signature polymorphic methods and >>>>>invokedynamic. >>>>> >>>>> Thanks, >>>>> Paul. >>>> I seems that the changes are not propagated to the JEP yet, >>>> but there are available throught the corresponding bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8046183 >>>> >>> Doh! thanks, i forgot to send the link out, >>> Paul, >> >> Here is a kind of counter-proposal because I think that there is a far >>simpler and more secure API. >> >> I think that instead of having to first instantiate an object >>(VarHandle) and then call a method on it, >> this can be done in one method. >> >> |public class Safe { >> @Intrinsic >> public staticObject get(Object receiver, String fieldName) { }| >> || @Intrinsic >> public staticObject getRelaxed(Object receiver, String fieldName) >>{ }| >> ||||@Intrinsic|| >> ||||public staticObject getAcquire(Object receiver, String >>fieldName) { }||| >> |||||| @Intrinsic||| >> ||||public staticObject getRelaxed(Object receiver, String >>fieldName) { }||| >> ||||| @Intrinsic|||| >> ||||public staticObject |||||||getSequential|(Object receiver, >>String fieldName) { }|| >> | >> |||||| @Intrinsic||||| >> |||public static void set(|||||||Object receiver, String >>fieldName|||, Object value) { }| >> // and all other related variations >> ... }| >> >> and this is how to use it: >> >> class Foo { >> >> | int i; >> >> public void acquire() { >> |||boolean r= (boolean)Safe.compareAndSet(this, "i", 0, 1); >> ... >> | } >> }| >> >> >> At compile time, the compiler checks that a method Safe.compareAndSet >>with compatible parameter types exists >> but instead of generating an invokestatic, it generates an >>invokedynamic which uses the signature of the actual callsite. >> Using the actual types in the signature allows to avoid unnecessary >>boxing while >> keeping the typechecking rules simples (they are not changed !) as >>explained in the current draft of JEP 193. >> >> This API doesn't use any object to represent a field but uses a String >>as field name, you may think that >> 1) this mean that the field will be queried each time: >> It doesn't has to. invokedynamic allow to install a dynamic check >>that will test that the string doesn't change >> from one call to another. This check will be removed by the JIT >>because the string never change >> (if the string change, the best is to throw a runtime exception like >>IllegalArgumentException explaining >> that the field name must be a constant). >> 2) that using a String is not typesafe. Having a typesafe API is hard >>here, because the type of a field >> is not something you can get at compile time, there is no field >>reference syntax in Java (no Foo::i), >> so a String seems to be a good practical choice. >> >> And this API has a true real advantage compared to the VarHandle API, >>this API is inherently more secure. >> A VarHandle or any object representing a field will have some special >>security credential because it can access >> to a field without having to check at runtime if the field is visible >>from where the call is done (for performance reason). >> From my own experience, it's too easy to make this kind of object too >>visible introduced a security hole without >> even doing something hard. >> By not reifying the access to a field as an object, the API is more >>secure with the restriction >> that a method can only access to the field of the class that contains >>the call to the API. >> >> In term of implementation, the compiler will generate this bytecode for >>the class Foo: >> >> ||class Foo { >> >> | int i; >> >> public void acquire() { >> invokedynamic "compareAndSet" (Foo;String;II)Z >> BSM >>=||java.lang.invoke.SafeMetaProtocol|||.bootstrap(Lookup;String;MethodTyp >>e;MethodHandle) >> ARG = MH(||||||Safe.compareAndSet(||Object;String;Object;Object;) >> istore 0|||| >> ... >> | } >> }| >> >> and from the JLS perspective, the compiler will recognize that the >>method inside Safe >> are special because there are annotated by an annotation that has a >>meta-annotation >> named BootstrapMethod that specifies the bootstrap method that should >>be used >> when emitting the invokedynamic call. >> >> |||| >> >> @BootstrapMethod(type=java.lang.invoke.SafeMetaProtocol.class, >>name="bootstrap") >> @interface Intrinsic { >> // empty >> } >> >> cheers, >> R?mi >> > From paul.sandoz at oracle.com Fri Oct 31 14:01:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Oct 2014 15:01:21 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <CAKOqNJ-g6mGAmz+vaomt1N3Z4y8Wvr-4CTSKO02UGfGCHvuaXA@mail.gmail.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> <CAKOqNJ-g6mGAmz+vaomt1N3Z4y8Wvr-4CTSKO02UGfGCHvuaXA@mail.gmail.com> Message-ID: <AF822B2C-B447-46A9-9CFE-A2083BEDC938@oracle.com> On Oct 30, 2014, at 9:37 PM, Georges Gomes <georges.gomes at gmail.com> wrote: > Hi Paul > > This looks really good this way. IMHO much better than previous proposal. > My only concern would be around refactorings. I guess it's only an IDE > problem... > But it needs to be manageable by IDE. > In that sense, Remy's proposal is slightly easier to manage by the IDEs no? Yes, probably a little easier for field access (array access is more involved). However, in my experience the process of modifying the j.u.concurrently classes and replacing Unsafe with VarHandle was not that arduous and rather quick. I suspect both would be easily amenable to some automatic transformation via an IDE [*]. Paul. [*] And maybe byte code transformations, which would be rather handy for testing with say jcstress tests. From paul.sandoz at oracle.com Fri Oct 31 15:18:06 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Oct 2014 16:18:06 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <D07942CA.BED39%duncan.macgregor@ge.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> <7342F03D-62A0-4750-9D2C-11082D3A751C@oracle.com> <D07942CA.BED39%duncan.macgregor@ge.com> Message-ID: <FF5C3D4E-52DB-4A61-8EE9-B0F56D909342@oracle.com> On Oct 31, 2014, at 2:57 PM, "MacGregor, Duncan (GE Energy Management)" <duncan.macgregor at ge.com> wrote: > I like the overall idea but also think the string feels wrong, it suggests > that both the class of the object and the field name could be dynamic and > might change with every invocation, but I really doubt we?d want that. Pedantically: the concrete class of the receiver object could change (e.g. sub-classes of ForkJoinTask) but should always be an instance of the receiver class. > If > we were to approach this from the callsite point of view then the type of > the site should specify the class which owns the field and the type of > that field, with the name specified by the String passed to the bsm, and > the Java syntax would have to make it obvious that those are not > dynamically changeable. > > How would we express operations on atomic fields with this scheme? > The initial version of the JEP could of expressed that (with a number of solutions for how such expressions could translate to byte code). It was a good attempt ("least-bad way at the time"), but we were not happy with it. Paul. From forax at univ-mlv.fr Fri Oct 31 15:59:57 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 31 Oct 2014 16:59:57 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <D07942CA.BED39%duncan.macgregor@ge.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> <7342F03D-62A0-4750-9D2C-11082D3A751C@oracle.com> <D07942CA.BED39%duncan.macgregor@ge.com> Message-ID: <5453B1FD.1020709@univ-mlv.fr> On 10/31/2014 02:57 PM, MacGregor, Duncan (GE Energy Management) wrote: > I like the overall idea but also think the string feels wrong, it suggests > that both the class of the object and the field name could be dynamic and > might change with every invocation, but I really doubt we?d want that. A previous iteration of the API (in my head) was using a class named FieldMirror like this: public class Safe { @Instrinsic public static <T, V> V get(T receiver, FieldMirror<T, V> fieldMirror) { } ... } public class FieldMirror<T, V> { public FieldMirror(Class<T> declaringClass, String fieldName, Class<V> fieldType) { ... } } class Foo { private static final FieldMirror<Foo, Integer> Foo_i = new FieldMirror<>(Foo.class, "i", int.class); int i; public int get() { return (int)Safe.get(this, Foo_i); } } In that case, the creation of the FieldMirror requires to check if the field exist and we need a supplementary check in the slow MH as Paul called it, to verify that the field mirror reference a visible field from the callsite. While sending a String is ugly, it avoids this double check. Duncan, as you can see, it also suggests that the field mirror taken as argument of Safe.get() can be dynamic too, so I don't see this API as an improvement, not compared to class Foo { private static final String Foo_i = "i"; int i; public int get() { return (int)Safe.get(this, Foo_i); } } As I said, apart if we have a compiler representation of a field reference, something like Foo::i, I think I prefer to stick with Strings. > [...] > > Regards, Duncan. R?mi > > On 31/10/2014 13:37, "Paul Sandoz" <paul.sandoz at oracle.com> wrote: > >> Hi Remi, >> >> Thanks, that's an interesting approach which has not previously occurred >> to me. >> >> So this proposal combines lookup and access into one call. IIUC to do >> that effectively the dynamic call site needs to initially provide a >> "slow" MH that performs an access-control-check, and then updates the >> call site (once only) with a MH performing the faster check that assumes >> the field identifier is held constant (and if not barfs). >> >> I find the use of the String a little raw, it does not uniquely identify >> a field, unless there is more information encoded, and is error prone >> when repeatedly declared. There is one less possible runtime exception >> for arity but that is counter balanced with one each for access control >> and constant-check per call-site. >> >> If we could introduce a more formal field identifier it would strengthen >> the proposal. So i think it worth keeping this idea around while seeing >> how we progress with handles and especially generic handles. >> >> >> We could perform similar checks on VarHandle invocation too with a >> dynamic call site, if such integrity [1] is a concern. For non-public >> fields, the slow path checks that the lookup class has access to the >> receiver class before proceeding [2], although that would then >> differentiate from MH behaviour. It could even be configured as something >> optional, or even perhaps programatically "these are the set of classes i >> give access permission". >> >> An obvious observation: existing Unsafe or Atomic*Update refs need to be >> guarded from leakage, so this pattern is not new or unexpected. When >> converting Unsafe usages to VarHandle it's quite simple to maintain that >> pattern. Further, it's possible have tooling that detect such leaks. >> >> Paul. >> >> [1] I am more concerned about integrity ("private" means private etc.) >> rather than security with a security manager. >> >> [2] Can such checks be folded away? >> >> >> On Oct 30, 2014, at 8:58 PM, Remi Forax <forax at univ-mlv.fr> wrote: >> >>> On 10/30/2014 04:53 PM, Paul Sandoz wrote: >>>> On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote: >>>> >>>>> On 10/30/2014 03:02 PM, Paul Sandoz wrote: >>>>>> Hi, >>>>>> >>>>>> I have, with the help of Brian, Doug and John, updated the >>>>>> description of JEP 193: Enhanced Volatiles to reflect our current >>>>>> thinking based on: >>>>>> >>>>>> - the prototype implementation in valhalla; >>>>>> - performance measurements of that implementation; and >>>>>> - investigations related to signature polymorphic methods and >>>>>> invokedynamic. >>>>>> >>>>>> Thanks, >>>>>> Paul. >>>>> I seems that the changes are not propagated to the JEP yet, >>>>> but there are available throught the corresponding bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8046183 >>>>> >>>> Doh! thanks, i forgot to send the link out, >>>> Paul, >>> Here is a kind of counter-proposal because I think that there is a far >>> simpler and more secure API. >>> >>> I think that instead of having to first instantiate an object >>> (VarHandle) and then call a method on it, >>> this can be done in one method. >>> >>> |public class Safe { >>> @Intrinsic >>> public staticObject get(Object receiver, String fieldName) { }| >>> || @Intrinsic >>> public staticObject getRelaxed(Object receiver, String fieldName) >>> { }| >>> ||||@Intrinsic|| >>> ||||public staticObject getAcquire(Object receiver, String >>> fieldName) { }||| >>> |||||| @Intrinsic||| >>> ||||public staticObject getRelaxed(Object receiver, String >>> fieldName) { }||| >>> ||||| @Intrinsic|||| >>> ||||public staticObject |||||||getSequential|(Object receiver, >>> String fieldName) { }|| >>> | >>> |||||| @Intrinsic||||| >>> |||public static void set(|||||||Object receiver, String >>> fieldName|||, Object value) { }| >>> // and all other related variations >>> ... }| >>> >>> and this is how to use it: >>> >>> class Foo { >>> >>> | int i; >>> >>> public void acquire() { >>> |||boolean r= (boolean)Safe.compareAndSet(this, "i", 0, 1); >>> ... >>> | } >>> }| >>> >>> >>> At compile time, the compiler checks that a method Safe.compareAndSet >>> with compatible parameter types exists >>> but instead of generating an invokestatic, it generates an >>> invokedynamic which uses the signature of the actual callsite. >>> Using the actual types in the signature allows to avoid unnecessary >>> boxing while >>> keeping the typechecking rules simples (they are not changed !) as >>> explained in the current draft of JEP 193. >>> >>> This API doesn't use any object to represent a field but uses a String >>> as field name, you may think that >>> 1) this mean that the field will be queried each time: >>> It doesn't has to. invokedynamic allow to install a dynamic check >>> that will test that the string doesn't change >>> from one call to another. This check will be removed by the JIT >>> because the string never change >>> (if the string change, the best is to throw a runtime exception like >>> IllegalArgumentException explaining >>> that the field name must be a constant). >>> 2) that using a String is not typesafe. Having a typesafe API is hard >>> here, because the type of a field >>> is not something you can get at compile time, there is no field >>> reference syntax in Java (no Foo::i), >>> so a String seems to be a good practical choice. >>> >>> And this API has a true real advantage compared to the VarHandle API, >>> this API is inherently more secure. >>> A VarHandle or any object representing a field will have some special >>> security credential because it can access >>> to a field without having to check at runtime if the field is visible >> >from where the call is done (for performance reason). >>> From my own experience, it's too easy to make this kind of object too >>> visible introduced a security hole without >>> even doing something hard. >>> By not reifying the access to a field as an object, the API is more >>> secure with the restriction >>> that a method can only access to the field of the class that contains >>> the call to the API. >>> >>> In term of implementation, the compiler will generate this bytecode for >>> the class Foo: >>> >>> ||class Foo { >>> >>> | int i; >>> >>> public void acquire() { >>> invokedynamic "compareAndSet" (Foo;String;II)Z >>> BSM >>> =||java.lang.invoke.SafeMetaProtocol|||.bootstrap(Lookup;String;MethodTyp >>> e;MethodHandle) >>> ARG = MH(||||||Safe.compareAndSet(||Object;String;Object;Object;) >>> istore 0|||| >>> ... >>> | } >>> }| >>> >>> and from the JLS perspective, the compiler will recognize that the >>> method inside Safe >>> are special because there are annotated by an annotation that has a >>> meta-annotation >>> named BootstrapMethod that specifies the bootstrap method that should >>> be used >>> when emitting the invokedynamic call. >>> >>> |||| >>> >>> @BootstrapMethod(type=java.lang.invoke.SafeMetaProtocol.class, >>> name="bootstrap") >>> @interface Intrinsic { >>> // empty >>> } >>> >>> cheers, >>> R?mi >>> From forax at univ-mlv.fr Fri Oct 31 16:02:02 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 31 Oct 2014 17:02:02 +0100 Subject: Update to description of JEP 193: Enhanced Volatiles In-Reply-To: <FF5C3D4E-52DB-4A61-8EE9-B0F56D909342@oracle.com> References: <8DE0C1E6-6B6A-4C0F-8C42-A37947B44AF6@oracle.com> <54525D8D.2080801@univ-mlv.fr> <D512DF73-FBEF-4AFF-929C-8FBF90435F38@oracle.com> <54529854.2090608@univ-mlv.fr> <7342F03D-62A0-4750-9D2C-11082D3A751C@oracle.com> <D07942CA.BED39%duncan.macgregor@ge.com> <FF5C3D4E-52DB-4A61-8EE9-B0F56D909342@oracle.com> Message-ID: <5453B27A.9060208@univ-mlv.fr> On 10/31/2014 04:18 PM, Paul Sandoz wrote: > >> If >> we were to approach this from the callsite point of view then the type of >> the site should specify the class which owns the field and the type of >> that field, with the name specified by the String passed to the bsm, and >> the Java syntax would have to make it obvious that those are not >> dynamically changeable. >> >> How would we express operations on atomic fields with this scheme? >> > The initial version of the JEP could of expressed that (with a number of solutions for how such expressions could translate to byte code). It was a good attempt ("least-bad way at the time"), but we were not happy with it. yes, if an API is wrong, use another one. If a language feature is wrong, it will stick forever. > > Paul. R?mi