From albert.noll at oracle.com Tue Nov 4 10:11:36 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 04 Nov 2014 11:11:36 +0100 Subject: Aggressive unboxing of values: status update Message-ID: <5458A658.7010105@oracle.com> Hi all, I've been working on aggressive unboxing of values over the past couple of weeks. The project is in a very early state. The current prototype is designed around two principles: (1) implement unboxing as described below, (2) keep the required changes reasonably small. As a result, there is lots of potential for optimization. These optimizations can be added in later stages of the project. Aggressive unboxing aims at providing an efficient way to: (1) pass values as parameters to functions (2) return values from functions (3) load and store flattened data in the heap (4) provide insight into the implementation of value types Let's consider this simple example: value Complex { int x, int y; private Complex(int x, int y) { this.x = x; this.y = y; } public static Complex make(int x, int y) { return new Complex(int x, int y); } } class Test { void non_inlined_callee(Complex c) { int sum = c.x + c.y; System.out.println(sum); } void caller() { Complex c = Complex.make(1, 2); non_inlined_callee(c); } } Let's assume that Complex.make() and the constructor in Complex.make() is inlined into caller(). The compiler decides to not inline non_inlined_callee(). The current prototype recognizes that 'Complex' is a value and uses the unboxed components (x and y) to pass them to non_inlined_callee. I.e., the JIT compiler transforms the original call 'non_inlined_callee(Complex c)' to 'non_inlined_callee(Complex c, int x, int y)'. Why to we keep the parameter 'Complex c'? The reason is that we want to keep - for now - the interpreter unmodified. I.e., by keeping 'Complex c' in the signature, non_inlined_callee() can call native methods, the interpreter, or a C1 compiled method. This is not optimal, but keeps things simple for now. In a later stage of the project, we plan to implement a 'boxing operation'. Boxing an unboxed value would be done only on demand. One thing that we need to think about is how we deal OOMEs when implementing 'lazy boxing'. If non_inlined_callee() is compiled with C2, the compiled code expects the unboxed parameters and uses the unboxed arguments instead of the original reference to 'Complex c'. One benefit of using the unboxed parameters instead of the original object is that the JIT needs to be less conservative and therefore the compiled code quality is potentially better. Providing this functionality (to prototype is not yet stable) requires changing ~2k lines in Hotspot. Many of the affected changes are in 'critical' places. That's why I want to make sure that the prototype is reasonably stable before pushing. Current support for unboxing is implemented only in C2. The interpreter and C1 can remain unchanged for now. I have a bachelor student who is looking into a corresponding C1 implementation. Development Plan: - Finish passing values as unboxed parameters for static methods - Return values in registers for static methods - Implement boxing operation - Pass 'this' unboxed - Make function calls without passing the allocated value object Best, Albert From brian.goetz at oracle.com Tue Nov 4 14:57:14 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 04 Nov 2014 09:57:14 -0500 Subject: Aggressive unboxing of values: status update In-Reply-To: <5458A658.7010105@oracle.com> References: <5458A658.7010105@oracle.com> Message-ID: <5458E94A.2000509@oracle.com> To put this in context: the question Albert is exploring here is "what if we didn't have to pessimistically preserve the identity of boxed primitives/values". Right now, when the VM sees an invocation to Integer.valueOf(int), it (a) can't tell whether the call was generated by the compiler or came from the source code, and (b) can't assume that the caller won't make use of the identity of the resulting box. The latter is especially frustrating as it cripples many useful optimizations, but in reality the identity is only used rarely. The rule for "lightweight boxes" (hboxes) that we're exploring here is: what if it were legal to box/unbox values/hboxes at will at any time, without affecting program semantics? Then, the identity of an hbox would be a pure implementation detail (note that we defined the identity of lambdas in this way too, what a coincidence!) Another way to think of this is normalizing boxing (rather than the box for 'int' being the hand-written class 'Integer', it is something mechanically derived from int and all other value types in the same way), formally declaring boxes unsuitable for identity-sensitive operations (which likely no one will miss), and pushing said normalized boxing out of the front-end compiler and into the VM (cue "selective sedimentation" discussion) where the VM has more control over representation. Where this may lead (we don't know yet, its an experiment), among other things, is it may reduce the invasiveness of specialization and expose more opportunities for the VM to dynamically make decisions about specialized classes. Currently specialization has to eagerly and unconditionally rewrite nearly all signatures and data-movement bytecodes before the class enters the VM; if boxing/unboxing can be made suitably cheap, this enables a less invasive rewriting that enables later binding to key decisions, so the VM is then in control of the tradeoff between footprint and type specificity, which is the sort of tradeoffs VMs are good at. On 11/4/2014 5:11 AM, Albert Noll wrote: > Hi all, > > I've been working on aggressive unboxing of values over the past couple > of weeks. The project is in a very early state. The current prototype is > designed around two principles: (1) implement unboxing as described > below, (2) keep the required changes reasonably small. As a result, > there is lots of potential for optimization. These optimizations can be > added in later stages of the project. Aggressive unboxing aims at > providing an efficient way to: > > (1) pass values as parameters to functions > (2) return values from functions > (3) load and store flattened data in the heap > (4) provide insight into the implementation of value types > > Let's consider this simple example: > > value Complex { > int x, int y; > private Complex(int x, int y) { > this.x = x; > this.y = y; > } > public static Complex make(int x, int y) { > return new Complex(int x, int y); > } > } > > class Test { > void non_inlined_callee(Complex c) { > int sum = c.x + c.y; > System.out.println(sum); > } > void caller() { > Complex c = Complex.make(1, 2); > non_inlined_callee(c); > } > } > > Let's assume that Complex.make() and the constructor in Complex.make() > is inlined into caller(). The compiler decides to not inline > non_inlined_callee(). The current prototype recognizes that 'Complex' is > a value and uses the unboxed components (x and y) to pass them to > non_inlined_callee. I.e., the JIT compiler transforms the original call > 'non_inlined_callee(Complex c)' to 'non_inlined_callee(Complex c, int x, > int y)'. Why to we keep the parameter 'Complex c'? The reason is that we > want to keep - for now - the interpreter unmodified. I.e., by keeping > 'Complex c' in the signature, non_inlined_callee() can call native > methods, the interpreter, or a C1 compiled method. > > This is not optimal, but keeps things simple for now. In a later stage > of the project, we plan to implement a 'boxing operation'. Boxing an > unboxed value would be done only on demand. One thing that we need to > think about is how we deal OOMEs when implementing 'lazy boxing'. > If non_inlined_callee() is compiled with C2, the compiled code expects > the unboxed parameters and uses the unboxed arguments instead of the > original reference to 'Complex c'. One benefit of using the unboxed > parameters instead of the original object is that the JIT needs to be > less conservative and therefore the compiled code quality is potentially > better. > Providing this functionality (to prototype is not yet stable) requires > changing ~2k lines in Hotspot. Many of the affected changes are in > 'critical' places. That's why I want to make sure that the prototype is > reasonably stable before pushing. Current support for unboxing is > implemented only in C2. The interpreter and C1 can remain unchanged for > now. I have a bachelor student who is looking into a corresponding C1 > implementation. > > Development Plan: > - Finish passing values as unboxed parameters for static methods > - Return values in registers for static methods > - Implement boxing operation > - Pass 'this' unboxed > - Make function calls without passing the allocated value object > > Best, > Albert From john.r.rose at oracle.com Tue Nov 4 20:35:20 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 Nov 2014 12:35:20 -0800 Subject: Aggressive unboxing of values: status update In-Reply-To: <5458E94A.2000509@oracle.com> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> Message-ID: <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> Thanks for the report, Albert. And thanks for summarizing the context, Brian. And here's a bit more... The concept of weak boxes (or as I like to say Heisenboxes) is that they have no stable identity, but simply carry a value payload. The current rules for identity in the JVM include the following onerous condition: If two references x and y are ever observed (or constructed) to be distinct (!= using acmp), they must always and everywhere after be maintained as distinct, even if they refer to objects which are behaviorally identical in all other respects. (The same is true if you replace "distinct" with "identical".) For an optimizer or JVM this means that, besides the values of the objects x, y, there is a tiny bit of extra information which has to be maintained and transmitted along with the objects. If we wanted to aggressively unbox java.lang.Integer fields, this means we would have to maintain some sort of version number along with the int32 value. As in, is this my own favorite copy of 10042, or is it my cousin's? That's tolerable if we can completely bound all uses of a variable (escape analysis succeeds) but it fails as soon as you start storing stuff in the heap for indefinite periods. (Imagine storing the version number with the int32 in fields. Not cool.) The version number is a straw man I pulled out of the air to illustrate the problem, but there are two classic approaches (besides admitting defeat) for dealing with the problem. The first is interning, as with Lisp symbols: Every distinct int32 value would have a unique reference. E.g., it would be a globally unique Integer object. Equivalently, the unique value would be a synthetic "fixnum" quasi-reference with special tag bits. (See my blog post "fixnums in the VM"[1].) This approach would interfere with the assumption that "new Integer" always produces a new reference, and (by doubling down on the uniqueness of the reference) appears to encourage the user to rely on the reference, requiring onerous hidden machinery in the VM to maintain the apparent uniqueness of the reference to 10042 (whether fiction or reality). The second classic approach is to declare that object identity (for some objects) is indeterminate, and allow the system to make local, decoupled decisions about boxing and unboxing. (See my blog post "value types in the VM"[2], and the JDK 8 concept of "value-based classes"[3].) That is the approach Albert is exploring. This approach is used in Common Lisp (and probably Smalltalk for all I know) to represent numeric value types, instead of giving guarantees about fixnums or interning. The Common Lisp spec has this interesting glimpse into our possible future[4]: > In Common Lisp, unlike some other Lisp dialects, the implementation is permitted to make ``copies'' of characters and numbers at any time. (This permission is granted because it allows tremendous performance improvements in many common situations.) The net effect is that Common Lisp makes no guarantee that eq will be true even when both its arguments are ``the same thing'' if that thing is a character or number. For example: > (let ((x 5)) (eq x x)) might be true or false. > The predicate eql is the same as eq, except that if the arguments are characters or numbers of the same type then their values are compared. Thus eql tells whether two objects are conceptually the same, whereas eq tells whether two objects are implementationally identical. One way to view our experiments with boxing is that we are experimenting with applying rules from the complete Common Lisp menu (symbols, fixnums, weak boxes, strong boxes?) to Java values. ? John P.S. I noticed while googling up references that there is (since 2012) a nice little Wikipedia article on value objects which collects references to these and related design questions[5]. [1] https://blogs.oracle.com/jrose/entry/fixnums_in_the_vm [2] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm [3] http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html [4] http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node74.html#SECTION001030000000000000000 [5] http://en.wikipedia.org/wiki/Value_object On Nov 4, 2014, at 6:57 AM, Brian Goetz wrote: > To put this in context: the question Albert is exploring here is "what if we didn't have to pessimistically preserve the identity of boxed primitives/values". Right now, when the VM sees an invocation to Integer.valueOf(int), it (a) can't tell whether the call was generated by the compiler or came from the source code, and (b) can't assume that the caller won't make use of the identity of the resulting box. The latter is especially frustrating as it cripples many useful optimizations, but in reality the identity is only used rarely. > > The rule for "lightweight boxes" (hboxes) that we're exploring here is: what if it were legal to box/unbox values/hboxes at will at any time, without affecting program semantics? Then, the identity of an hbox would be a pure implementation detail (note that we defined the identity of lambdas in this way too, what a coincidence!) > > Another way to think of this is normalizing boxing (rather than the box for 'int' being the hand-written class 'Integer', it is something mechanically derived from int and all other value types in the same way), formally declaring boxes unsuitable for identity-sensitive operations (which likely no one will miss), and pushing said normalized boxing out of the front-end compiler and into the VM (cue "selective sedimentation" discussion) where the VM has more control over representation. > > Where this may lead (we don't know yet, its an experiment), among other things, is it may reduce the invasiveness of specialization and expose more opportunities for the VM to dynamically make decisions about specialized classes. Currently specialization has to eagerly and unconditionally rewrite nearly all signatures and data-movement bytecodes before the class enters the VM; if boxing/unboxing can be made suitably cheap, this enables a less invasive rewriting that enables later binding to key decisions, so the VM is then in control of the tradeoff between footprint and type specificity, which is the sort of tradeoffs VMs are good at. > > On 11/4/2014 5:11 AM, Albert Noll wrote: >> Hi all, >> >> I've been working on aggressive unboxing of values over the past couple >> of weeks. The project is in a very early state. The current prototype is >> designed around two principles: (1) implement unboxing as described >> below, (2) keep the required changes reasonably small. As a result, >> there is lots of potential for optimization. These optimizations can be >> added in later stages of the project. Aggressive unboxing aims at >> providing an efficient way to: >> >> (1) pass values as parameters to functions >> (2) return values from functions >> (3) load and store flattened data in the heap >> (4) provide insight into the implementation of value types >> >> Let's consider this simple example: >> >> value Complex { >> int x, int y; >> private Complex(int x, int y) { >> this.x = x; >> this.y = y; >> } >> public static Complex make(int x, int y) { >> return new Complex(int x, int y); >> } >> } >> >> class Test { >> void non_inlined_callee(Complex c) { >> int sum = c.x + c.y; >> System.out.println(sum); >> } >> void caller() { >> Complex c = Complex.make(1, 2); >> non_inlined_callee(c); >> } >> } >> >> Let's assume that Complex.make() and the constructor in Complex.make() >> is inlined into caller(). The compiler decides to not inline >> non_inlined_callee(). The current prototype recognizes that 'Complex' is >> a value and uses the unboxed components (x and y) to pass them to >> non_inlined_callee. I.e., the JIT compiler transforms the original call >> 'non_inlined_callee(Complex c)' to 'non_inlined_callee(Complex c, int x, >> int y)'. Why to we keep the parameter 'Complex c'? The reason is that we >> want to keep - for now - the interpreter unmodified. I.e., by keeping >> 'Complex c' in the signature, non_inlined_callee() can call native >> methods, the interpreter, or a C1 compiled method. >> >> This is not optimal, but keeps things simple for now. In a later stage >> of the project, we plan to implement a 'boxing operation'. Boxing an >> unboxed value would be done only on demand. One thing that we need to >> think about is how we deal OOMEs when implementing 'lazy boxing'. >> If non_inlined_callee() is compiled with C2, the compiled code expects >> the unboxed parameters and uses the unboxed arguments instead of the >> original reference to 'Complex c'. One benefit of using the unboxed >> parameters instead of the original object is that the JIT needs to be >> less conservative and therefore the compiled code quality is potentially >> better. >> Providing this functionality (to prototype is not yet stable) requires >> changing ~2k lines in Hotspot. Many of the affected changes are in >> 'critical' places. That's why I want to make sure that the prototype is >> reasonably stable before pushing. Current support for unboxing is >> implemented only in C2. The interpreter and C1 can remain unchanged for >> now. I have a bachelor student who is looking into a corresponding C1 >> implementation. >> >> Development Plan: >> - Finish passing values as unboxed parameters for static methods >> - Return values in registers for static methods >> - Implement boxing operation >> - Pass 'this' unboxed >> - Make function calls without passing the allocated value object >> >> Best, >> Albert From maurizio.cimadamore at oracle.com Wed Nov 5 17:15:43 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 05 Nov 2014 17:15:43 +0000 Subject: hg: valhalla/valhalla/langtools: Add better wildcards support for 'any' type-variables Message-ID: <201411051715.sA5HFhIk017342@aojmv0008> Changeset: 1bab9afd02bf Author: mcimadamore Date: 2014-11-05 17:15 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/1bab9afd02bf Add better wildcards support for 'any' type-variables * ? extends/super T should be allowed for 'any' T * unbounded wildcards still map to ? extends Object ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java + test/tools/javac/valhalla/typespec/Wildcards03.java + test/tools/javac/valhalla/typespec/Wildcards03.out ! test/tools/javac/valhalla/typespec/items/tests/TestAnyMembers.java From brian.goetz at oracle.com Fri Nov 7 20:37:15 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 07 Nov 2014 20:37:15 +0000 Subject: hg: valhalla/valhalla/jdk: Improved handling of signatures with wildcards in specializer Message-ID: <201411072037.sA7KbGOt026743@aojmv0008> Changeset: 22181ff8cecd Author: briangoetz Date: 2014-11-07 15:36 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/22181ff8cecd Improved handling of signatures with wildcards in specializer ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! test/valhalla/test/valhalla/specializer/SignatureVisitorTest.java From brian.goetz at oracle.com Fri Nov 7 22:31:55 2014 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 07 Nov 2014 22:31:55 +0000 Subject: hg: valhalla/valhalla/jdk: Hack ASM signature parser to not be confused by +TT; in illegal positions; more wildcard tests Message-ID: <201411072231.sA7MVthJ017133@aojmv0008> Changeset: a284b657c6e8 Author: briangoetz Date: 2014-11-07 17:31 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a284b657c6e8 Hack ASM signature parser to not be confused by +TT; in illegal positions; more wildcard tests ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java + test/valhalla/test/valhalla/specializer/WildcardTest.java From simon at ochsenreither.de Sat Nov 8 15:11:05 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Sat, 8 Nov 2014 16:11:05 +0100 (CET) Subject: Changes to signatures? In-Reply-To: <544E63A6.9080403@oracle.com> References: <544DE450.9080607@ochsenreither.de> <544E4D4B.7050805@oracle.com> <544E5CEA.8030900@ochsenreither.de> <544E63A6.9080403@oracle.com> Message-ID: <1400153772.64851.1415459465492.JavaMail.open-xchange@srv005.service.ps-server.net> Hi Brian, sorry for my late reply. > 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.) I think it really depends on the expressivity of the various signatures. As far as I currently see it, the BytecodeMapping attribute tries to encode the bare minimum, which might be easier to support in different compilers than Generic Signatures. Generic Signatures are kind of "optional" currently and aren't really checked for consistency, and scalac doesn't really try too hard to emit sensible sigantures, because most intersting things can't be expressed in Java anyway. So any change to that status quo would certainly have a (likely negative) impact. > 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. This sounds like a reasonable concern. The only thing I'm worried about is that it might even further increase the time until tools like ASM (and therefore other languages) might support this, increasing the delay of implementation and feedback from implementors. Thanks and bye, Simon From simon at ochsenreither.de Sat Nov 8 15:20:37 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Sat, 8 Nov 2014 16:20:37 +0100 (CET) Subject: Aggressive unboxing of values: status update In-Reply-To: <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> Message-ID: <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> Hi John, could you expand a bit on the desire to unbox Integer fields in this fashion? This strategy really reminds of the way things ended up with int vs. Integer in the first place: Smashing two, mostly incompatible sets of requirements together ... I'm not sure that doing that again will result in a more favorable outcome. > One way to view our experiments with boxing is that we are experimenting with > applying rules from the complete Common Lisp menu (symbols, fixnums, weak > boxes, strong boxes?) to Java values. This is scary. Even the current semantics in Java/the JVM are a mes in this parts, adding additional layers on top of it feels like making the issue even worse. What's wrong with just having value boxes, which make value types work in situation where they can't be passed as a value, and nothing else? (Sorry if my impression of these ideas is completely wrong or I misunderstood something.) From simon at ochsenreither.de Sat Nov 8 15:57:08 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Sat, 8 Nov 2014 16:57:08 +0100 (CET) Subject: Changes to signatures? In-Reply-To: <545E3602.8020206@oracle.com> References: <544DE450.9080607@ochsenreither.de> <544E4D4B.7050805@oracle.com> <544E5CEA.8030900@ochsenreither.de> <544E63A6.9080403@oracle.com> <916826472.64835.1415459264196.JavaMail.open-xchange@srv005.service.ps-server.net> <545E3602.8020206@oracle.com> Message-ID: <1075814239.64968.1415462228499.JavaMail.open-xchange@srv005.service.ps-server.net> Hi Brian! > The ASM guys have been pretty good about keeping up with the latest > changes in bytecode; other tools, not so much. Oh, that's great! I must have missed that. Is the ASM-for-Java-10 code accessible somewhere? Thanks, Simon From forax at univ-mlv.fr Sat Nov 8 17:12:16 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 08 Nov 2014 18:12:16 +0100 Subject: Changes to signatures? In-Reply-To: <1075814239.64968.1415462228499.JavaMail.open-xchange@srv005.service.ps-server.net> References: <544DE450.9080607@ochsenreither.de> <544E4D4B.7050805@oracle.com> <544E5CEA.8030900@ochsenreither.de> <544E63A6.9080403@oracle.com> <916826472.64835.1415459264196.JavaMail.open-xchange@srv005.service.ps-server.net> <545E3602.8020206@oracle.com> <1075814239.64968.1415462228499.JavaMail.open-xchange@srv005.service.ps-server.net> Message-ID: <545E4EF0.6070605@univ-mlv.fr> On 11/08/2014 04:57 PM, Simon Ochsenreither wrote: > Hi Brian! > >> The ASM guys have been pretty good about keeping up with the latest >> changes in bytecode; other tools, not so much. > > Oh, that's great! I must have missed that. Is the ASM-for-Java-10 code > accessible somewhere? There is an experimental branch here: http://websvn.ow2.org/listing.php?repname=asm&path=%2Fbranches%2FVALHALLA%2Fasm%2F but it is not in sync with the latest changes. > > Thanks, > > Simon cheers, R?mi From brian.goetz at oracle.com Sat Nov 8 17:24:39 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 08 Nov 2014 12:24:39 -0500 Subject: Changes to signatures? In-Reply-To: <1075814239.64968.1415462228499.JavaMail.open-xchange@srv005.service.ps-server.net> References: <544DE450.9080607@ochsenreither.de> <544E4D4B.7050805@oracle.com> <544E5CEA.8030900@ochsenreither.de> <544E63A6.9080403@oracle.com> <916826472.64835.1415459264196.JavaMail.open-xchange@srv005.service.ps-server.net> <545E3602.8020206@oracle.com> <1075814239.64968.1415462228499.JavaMail.open-xchange@srv005.service.ps-server.net> Message-ID: <545E51D7.3020604@oracle.com> That will come. Since right now, the classfile changes are totally experimental and ad-hoc, it is probably not worth trying to track them until they stabilize. (We do have custom attribute implementations for the new attributes, but they're in the valhalla.specializer package, not the ASM packages, until they're stabilized.) On 11/8/2014 10:57 AM, Simon Ochsenreither wrote: > Hi Brian! > > > The ASM guys have been pretty good about keeping up with the latest > > changes in bytecode; other tools, not so much. > Oh, that's great! I must have missed that. Is the ASM-for-Java-10 code > accessible somewhere? > Thanks, > Simon From albert.noll at oracle.com Mon Nov 10 07:57:23 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 10 Nov 2014 08:57:23 +0100 Subject: Aggressive unboxing of values: status update In-Reply-To: <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> Message-ID: <54606FE3.8070609@oracle.com> Hi Simon, please see comments inline. On 11/08/2014 04:20 PM, Simon Ochsenreither wrote: > Hi John, > could you expand a bit on the desire to unbox Integer fields in this > fashion? > This strategy really reminds of the way things ended up with int vs. > Integer in the first place: Smashing two, mostly incompatible sets of > requirements together ... I'm not sure that doing that again will > result in a more favorable outcome. > > > One way to view our experiments with boxing is that we are > experimenting with applying rules from the complete Common Lisp menu > (symbols, fixnums, weak boxes, strong boxes?) to Java values. > This is scary. Even the current semantics in Java/the JVM are a mes in > this parts, adding additional layers on top of it feels like making > the issue even worse. > What's wrong with just having value boxes, which make value types work > in situation where they can't be passed as a value, and nothing else? There is nothing wrong with having boxes. One part of the development plan is to implement a boxing operation. Did you have a look at the "Boxing and object interoperability" section of this document? http://cr.openjdk.java.net/~jrose/values/values-0.html Best, Albert > (Sorry if my impression of these ideas is completely wrong or I > misunderstood something.) From simon at ochsenreither.de Mon Nov 10 15:34:04 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Mon, 10 Nov 2014 16:34:04 +0100 Subject: Aggressive unboxing of values: status update In-Reply-To: <54606FE3.8070609@oracle.com> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> <54606FE3.8070609@oracle.com> Message-ID: <5460DAEC.9080308@ochsenreither.de> Hi Albert, > There is nothing wrong with having boxes. One part of the development > plan is to implement a boxing operation. Did you have a look at the > "Boxing and object interoperability" section of this document? > > http://cr.openjdk.java.net/~jrose/values/values-0.html Yes, I'm aware of that. It's just not very helpful, because most interesting cases and issues are not covered. I'm questioning the idea of a) having Integer act as a value box for int, b) putting all the same requirements on value boxes; from my experience, trying to retrofit Integer as a value box for int is a futile endeavor, as well as weighing down other value boxes with things like reference equality etc. in the way John described in his mail. Thanks and bye, Simon From vlad.ureche at gmail.com Tue Nov 11 02:08:28 2014 From: vlad.ureche at gmail.com (Vlad Ureche) Date: Tue, 11 Nov 2014 03:08:28 +0100 Subject: Aggressive unboxing of values: status update In-Reply-To: <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> Message-ID: 2014-11-04 21:35 GMT+01:00 John Rose : > > The second classic approach is to declare that object identity (for some > objects) is indeterminate, and allow the system to make local, decoupled > decisions about boxing and unboxing. (See my blog post "value types in the > VM"[2], and the JDK 8 concept of "value-based classes"[3].) That is the > approach Albert is exploring. This approach is used in Common Lisp (and > probably Smalltalk for all I know) to represent numeric value types, > instead of giving guarantees about fixnums or interning. The Common Lisp > spec has this interesting glimpse into our possible future[4]: Would it make sense to supplement this assumption with a vm warning when boxed value identity is exposed? Like printing a message on VM exit: "The program you executed uses reference comparisons on boxed values, which are known to be non-deterministic. See http://... for more information and use -XX:+ErrorOnValueReferenceEquality to trigger an error when such a comparison occurs."? Vlad Ureche scala-miniboxing.org From brian.goetz at oracle.com Tue Nov 11 08:10:49 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Nov 2014 09:10:49 +0100 Subject: Aggressive unboxing of values: status update In-Reply-To: <5460DAEC.9080308@ochsenreither.de> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> <54606FE3.8070609@oracle.com> <5460DAEC.9080308@ochsenreither.de> Message-ID: >> There is nothing wrong with having boxes. One part of the development plan is to implement a boxing operation. Did you have a look at the "Boxing and object interoperability" section of this document? >> >> http://cr.openjdk.java.net/~jrose/values/values-0.html > Yes, I'm aware of that. It's just not very helpful, because most interesting cases and issues are not covered. That?s because we?re just getting started! We don?t know the answers to all the questions yet. Please be patient. > > I'm questioning the idea of > a) having Integer act as a value box for int, You should be questioning this ? it?s questionable. > b) putting all the same requirements on value boxes; > from my experience, trying to retrofit Integer as a value box for int is a futile endeavor, as well as weighing down other value boxes with things like reference equality etc. in the way John described in his mail. It is quite likely that Integer will not be suitable as a box for int when all is said and done; we?re trying to be open minded and not disqualify prematurely. From asviraspossible at gmail.com Tue Nov 11 12:37:36 2014 From: asviraspossible at gmail.com (Victor Nazarov) Date: Tue, 11 Nov 2014 16:37:36 +0400 Subject: Aggressive unboxing of values: status update In-Reply-To: References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> <54606FE3.8070609@oracle.com> <5460DAEC.9080308@ochsenreither.de> Message-ID: I don't know where to leave suggestions. But I'd like to state some of my ideas as I haven't heard something like this considered for implementation of value types. I don't advocate any of this as one true way. I just want to provide some input during exploration phase until it is to late. 1) Maybe it's time to make value types not equalTestable and not toStringable. As I understand value-types are not required to inherit from Object. I think It should be considered an option to refactor Object class into one explicitly implementing set of default interfaces: class Object implements EqualTestable, ToStringable, Hashable { } interface EqaulTestable { boolean equals(T other); } interface ToStringable { String toString(); } interface Hashable { int hashCode(); } Value-types are not required to implement any of these. They should choose what interfaces makes sense for each distinct type. And compiler should mark illegal calls to these interfaces. Classes can explicitly state requirements for type variables like: class HashMap, any V> { ... } 2) Add conditional interface implementations. It's already on agenda to add specializations and specializated methods. I hope that Java can provide more structured and more powerfull specializations. Current proposal is something like interface List { T removeAt(int index); void remove(T value); default T remove(int index) { return removeAt(index); } } I'd like to add some structure to specializations. Instead of bare conditional method declarations I'd like to have conditional interface implementations interface ObjectList { T remove(int index) } interface List extends ObjectList { T removeAt(int index); default T removeAt(int index) { return remove(index); } void remove(T value); } Many interfaces can be additionally refined to provide more convenience methods with such conditional interface implementations interface ComparableList { T max(); T min(); } List extends > ComparableList { T max() { ... } T min() { ... } } Victor Nazarov On Tue, Nov 11, 2014 at 11:10 AM, Brian Goetz wrote: > >> There is nothing wrong with having boxes. One part of the development > plan is to implement a boxing operation. Did you have a look at the "Boxing > and object interoperability" section of this document? > >> > >> http://cr.openjdk.java.net/~jrose/values/values-0.html > > Yes, I'm aware of that. It's just not very helpful, because most > interesting cases and issues are not covered. > > That?s because we?re just getting started! We don?t know the answers to > all the questions yet. Please be patient. > > > > > I'm questioning the idea of > > a) having Integer act as a value box for int, > > You should be questioning this ? it?s questionable. > > > b) putting all the same requirements on value boxes; > > > from my experience, trying to retrofit Integer as a value box for int is > a futile endeavor, as well as weighing down other value boxes with things > like reference equality etc. in the way John described in his mail. > > It is quite likely that Integer will not be suitable as a box for int when > all is said and done; we?re trying to be open minded and not disqualify > prematurely. > > > From paul.sandoz at oracle.com Tue Nov 11 14:08:44 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 11 Nov 2014 15:08:44 +0100 Subject: Aggressive unboxing of values: status update In-Reply-To: References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> <54606FE3.8070609@oracle.com> <5460DAEC.9080308@ochsenreither.de> Message-ID: On Nov 11, 2014, at 9:10 AM, Brian Goetz wrote: > > It is quite likely that Integer will not be suitable as a box for int when all is said and done; we?re trying to be open minded and not disqualify prematurely. > > Right let's not throw this away just yet, there might be valid cases in certain contexts such as auto-boxing or within method handle chains. Paul. From simon at ochsenreither.de Tue Nov 11 17:10:16 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Tue, 11 Nov 2014 18:10:16 +0100 (CET) Subject: Aggressive unboxing of values: status update In-Reply-To: References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> <54606FE3.8070609@oracle.com> <5460DAEC.9080308@ochsenreither.de> Message-ID: <2060604636.87161.1415725816646.JavaMail.open-xchange@srv005.service.ps-server.net> Hi Victor! As mentioned in an earlier email, it would certainly be desirable from a Scala point of view to have a "clean" Top type.? The question just is how you deal with code, which just assumes that everything is boxable (and has those methods)? Even if T in "any T" could be made completely memberless, what would happen when passing such a value type to a non-specialized T or assigning it to Object? Or would it be necessary to specify that value types just can't be boxed in non-specialized code (Object box, not value box)? That would probably make every bit of written code incompatible with value types. :-/ ? I think the reason why Scala devs are not really pushing for it is because in Java it would require some approach to "re-add" those members (as you mentioned in your mail), and in Java pretty much all you get are upper bounds. Imagine how fun writing Java will be with an additional layer of upper bounds to many type variables ... javac can hardly deal with the existing amount of Generics, and I'd prefer not having to handle even more Generics coming from Java. So even if Scala makes the Top type/T memberless, I think it will just do it as "compiler-fiction", because the things required to implement the concept in Java would be so terrible that it would negate the benefits. (Just my impression.) (I'm very wary about the glorified #idefs proposed for deciding what method exists in erased/specialized classes. (Deprecate the affected methods instead?)) Thanks and bye, Simon From john.r.rose at oracle.com Tue Nov 11 19:35:53 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 Nov 2014 11:35:53 -0800 Subject: Aggressive unboxing of values: status update In-Reply-To: References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <1762425921.64888.1415460037725.JavaMail.open-xchange@srv005.service.ps-server.net> <54606FE3.8070609@oracle.com> <5460DAEC.9080308@ochsenreither.de> Message-ID: <0CAC8408-276D-43AC-BD40-584276132FAD@oracle.com> On Nov 11, 2014, at 4:37 AM, Victor Nazarov wrote: > But I'd like to state some of my > ideas as I haven't heard something like this considered for implementation > of value types. The theme of both of your suggestions is to make deeper use of interfaces to distinguish and control the object-like and number-like features of values. Please read http://cr.openjdk.java.net/~jrose/values/values-0.html for a sample of our discussions. The details of your suggestions tend towards "splitting" independent features into separate interfaces. This is degree of freedom in API design which can be moved along a spectrum from "everything in Object" to "every method in its own interface". (See also http://en.wikipedia.org/wiki/Lumpers_and_splitters .) We are definitely discussing using interfaces with values in these ways. The values document explicitly contemplates such uses. (We would be crazy not to!) See two excerpts below; the second one proposes a "lumpier" interface than yours, which is purely provisional. The Haskell and Scala communities have invested enormous efforts exploring these areas, often with a splitting tendency in their API designs. One big challenge for designing Java value APIs is to adopt the best insights from such projects, but adapt them to the common style of Java APIs. Those APIs tend towards lumping, in order to reduce type count and provide a simpler initial experience. ? John > Besides `Object`, other types such as `Comparable` should > also be able to interoperate with suitable value types, > opening the door to types like `TreeSet`. > (This implies that interfaces may sometimes claim subtypes > which are not also subtypes of `Object`.) > We expect every value to implement an ad hoc interface or abstract > super type that looks something like this: > > interface __Objectable { > default String toString() {...} > default int hashCode() {...} > default boolean equals(ThisType) {...} > } From john.r.rose at oracle.com Tue Nov 11 19:42:26 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 Nov 2014 11:42:26 -0800 Subject: Aggressive unboxing of values: status update In-Reply-To: References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> Message-ID: <6B10625B-D52F-4890-8C2E-267FD6A8BBFC@oracle.com> On Nov 10, 2014, at 6:08 PM, Vlad Ureche wrote: > 2014-11-04 21:35 GMT+01:00 John Rose : > >> >> The second classic approach is to declare that object identity (for some >> objects) is indeterminate, and allow the system to make local, decoupled >> decisions about boxing and unboxing. (See my blog post "value types in the >> VM"[2], and the JDK 8 concept of "value-based classes"[3].) That is the >> approach Albert is exploring. This approach is used in Common Lisp (and >> probably Smalltalk for all I know) to represent numeric value types, >> instead of giving guarantees about fixnums or interning. The Common Lisp >> spec has this interesting glimpse into our possible future[4]: > > > Would it make sense to supplement this assumption with a vm warning when > boxed value identity is exposed? Like printing a message on VM exit: "The > program you executed uses reference comparisons on boxed values, which are > known to be non-deterministic. See http://... for more information and use > -XX:+ErrorOnValueReferenceEquality to trigger an error when such a > comparison occurs."? Yes, starting with synchronization on "foo".intern() and Integer.valueOf(42). Diagnosing invalid use of acmp is harder and will have performance costs, so might be useful only in a "-Xstrict" mode for testing. Note that the common idiom "a == b || a.equals(b)" is, practically speaking, a valid use of acmp for value boxes. If a or b is a heisenbox, "a == b" might always be false, causing a call to a.equals(b) which computes the intended boolean. ? John From maurizio.cimadamore at oracle.com Wed Nov 12 20:03:26 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 12 Nov 2014 20:03:26 +0000 Subject: hg: valhalla/valhalla/langtools: Add refined support for method specialization constraints: Message-ID: <201411122003.sACK3Roe029704@aojmv0008> Changeset: cb1ec9c62997 Author: mcimadamore Date: 2014-11-12 20:02 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/cb1ec9c62997 Add refined support for method specialization constraints: * removed __RefOnly keyword * new fine-grained __WhereRef(X) and __WhereVal(X) constructs to define context-dependent type-variable semantics * restructured javac pipeline to work with the new keywords/constructs * Added new bytecode attribute (Where) to store type-variable constraints Notes: * __WhereVal is currently not supported and will cause compiler crashes. * ASM and specializer support to follow. ! src/jdk.compiler/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java + src/jdk.compiler/share/classes/com/sun/tools/classfile/Where_attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! 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 ! 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/ClassWriter.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/processing/JavacProcessingEnvironment.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 ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/tools/javac/MethodParameters/AttributeVisitor.java ! test/tools/javac/diags/examples/DoesNotDefineConstr.java - test/tools/javac/diags/examples/IllegalRefOnlyCall.java + test/tools/javac/diags/examples/IllegalRestrictedCall.java + test/tools/javac/diags/examples/IllegalWhereDef.java - test/tools/javac/diags/examples/RedundantRefOnlyDef.java + test/tools/javac/diags/examples/RedundantWhereDef.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/TestRefOnly03.java ! 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/TestRefOnly07.java ! test/tools/javac/valhalla/typespec/TestRefOnly07.out ! test/tools/javac/valhalla/typespec/TestRefOnly08.java ! test/tools/javac/valhalla/typespec/TestRefOnly08.out ! test/tools/javac/valhalla/typespec/TestRefOnly09.java ! test/tools/javac/valhalla/typespec/items/tests/TestRefOnly.java + test/tools/javac/valhalla/typespec/separate03/A.java + test/tools/javac/valhalla/typespec/separate03/TestSeparate.java + test/tools/javac/valhalla/typespec/separate03/TestSeparate.out From simon at ochsenreither.de Thu Nov 13 03:21:30 2014 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Thu, 13 Nov 2014 04:21:30 +0100 (CET) Subject: Aggressive unboxing of values: status update In-Reply-To: <6B10625B-D52F-4890-8C2E-267FD6A8BBFC@oracle.com> References: <5458A658.7010105@oracle.com> <5458E94A.2000509@oracle.com> <1E8E12D9-F66B-40D9-B5D4-C8E5124B7F95@oracle.com> <6B10625B-D52F-4890-8C2E-267FD6A8BBFC@oracle.com> Message-ID: <1567097095.99121.1415848890325.JavaMail.open-xchange@srv005.service.ps-server.net> > Note that the common idiom "a == b || a.equals(b)" is, practically speaking, > a valid use of acmp for value boxes. If a or b is a heisenbox, "a == b" might > always be false, causing a call to a.equals(b) which computes the intended > boolean. What about the other way around? Instead of trying to figure out a way to add more or less non-sensical implementations of ==/equals to value boxes, make them really thin wrappers around value types, forwarding ==/equals to the value type's definition. This is would very likely lead to an approach where we could say "within specialized code, all value types (including primitives) have only one boxed representation: the value box". (I think this would be vastly less complex than e. g. having to deal with double, Double and box(double) in specialized code.)? This would only leave us with the question of what happens with value types in non-specialized code, e. g. when you do "Object obj = someValueType": I think it would be reasonable to have somewhat heavier "wrapper types" for value types (like the current wrapper types for primitives), which would come with all the baggage of object identity, being synchronizable etc. Optionally, if a developer would require such a heavier representation within specialized code, it would be possible to let him/her opt in with something like , and disallow operations which would require such boxing otherwise. ? I think having to deal with primitives, value boxes and wrapper types will easily eat any available complexity budget. WDYT? Thanks, Simon From maurizio.cimadamore at oracle.com Thu Nov 13 13:34:15 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Nov 2014 13:34:15 +0000 Subject: hg: valhalla/valhalla/jdk: Add support for 'Where' attribute Message-ID: <201411131334.sADDYGGd028148@aojmv0008> Changeset: de41429edb7a Author: mcimadamore Date: 2014-11-13 13:30 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/de41429edb7a Add support for 'Where' attribute * Specializer now skips methods whose 'where clauses' do not match ongoing specializaton * Added test ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java + src/java.base/share/classes/valhalla/specializer/WhereAttribute.java + test/valhalla/test/valhalla/specializer/WhereRefTest.java From maurizio.cimadamore at oracle.com Thu Nov 13 17:40:06 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Nov 2014 17:40:06 +0000 Subject: hg: valhalla/valhalla/jdk: Fix: URLClassLoader only reads first block of template class Message-ID: <201411131740.sADHe6wT014276@aojmv0008> Changeset: 83dd17a0fac0 Author: mcimadamore Date: 2014-11-13 17:36 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/83dd17a0fac0 Fix: URLClassLoader only reads first block of template class ! src/java.base/share/classes/java/net/URLClassLoader.java From maurizio.cimadamore at oracle.com Fri Nov 14 17:20:19 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Nov 2014 17:20:19 +0000 Subject: hg: valhalla/valhalla/langtools: Add type-system and codegen support for __WhereVal(X) construct. Message-ID: <201411141720.sAEHKJTq024244@aojmv0008> Changeset: f5d5382b9eec Author: mcimadamore Date: 2014-11-14 17:16 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/f5d5382b9eec Add type-system and codegen support for __WhereVal(X) construct. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.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/TypeTag.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/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.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 ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/valhalla/typespec/TestRefOnly02.java + test/tools/javac/valhalla/typespec/TestValOnly01.java + test/tools/javac/valhalla/typespec/TestValOnly01.out + test/tools/javac/valhalla/typespec/TestValOnly02.java + test/tools/javac/valhalla/typespec/TestValOnly02.out + test/tools/javac/valhalla/typespec/TestValOnly03.java + test/tools/javac/valhalla/typespec/TestValOnly03.out + test/tools/javac/valhalla/typespec/items/tests/TestValOnly.java From maurizio.cimadamore at oracle.com Fri Nov 14 17:39:20 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Nov 2014 17:39:20 +0000 Subject: hg: valhalla/valhalla/jdk: Add test for __WhereVal Message-ID: <201411141739.sAEHdL2R027138@aojmv0008> Changeset: 2d4531473a89 Author: mcimadamore Date: 2014-11-14 17:35 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2d4531473a89 Add test for __WhereVal - test/valhalla/test/valhalla/specializer/WhereRefTest.java + test/valhalla/test/valhalla/specializer/WhereTest.java From joerg at j-hohwiller.de Sat Nov 15 21:20:14 2014 From: joerg at j-hohwiller.de (=?ISO-8859-15?Q?J=F6rg_Hohwiller?=) Date: Sat, 15 Nov 2014 22:20:14 +0100 Subject: value types and support by various frameworks Message-ID: <5467C38E.5060505@j-hohwiller.de> Dear valhalla heros, I am new here and want to introduce myself. I am coding Java for 15 years now both in business and in private (open source projects). IMHO Java was probably never the best language of the universe by itself but it surely has one of the greatest eco-systems and it continuously evolves over time. What I missed from the start are proper value types and if I understood correctly that is currently on your roadmap. I always liked the way scala differs value and object types. We will probably never get rid of int vs. Integer but I have seen your paper [1] and this looks very promising. While I am probably not the one to contribute on JVM level I might still be of some use for considering integration with various frameworks of the eco-system. In the end it will be desired that JAXB, JPA vendors, JSON serializers, etc. will be capable of handing value types smooth for marshalling and esp. un-marshalling. Due to the lack of real value type support, I created a marker interface for a datatype that I missed in the JDK - see [2]. For the most common form, an atomic type, I created [3]. For hibernate and jackson I created generic adapters so that datatypes implementing the interfaces are automatically supported. If one fine day value types will become reality it would be awesome if such support would be given OOTB for all this frameworks. I would be happy to assist you with discussing and supporting various frameworks as I am in contact with key developers already. If there are other ideas where you think I could help, please let me know. BTW: is this also the place for general discussions about making Java better? E.g. JavaDoc could get some improvements and the lack of real property support for java beans is a bigger pain as most people might think in the first place. And have you seen projects like Knorxx or Dragome? I once started a big project in creating a PoC for a "JEE API" for rich clients that allows to create a rich client that runs both with JavaFx and in a browser (using Google Web Toolkit) - see [4]. JavaScript is the new answer for web clients and JSF will die out on the long run. But there is always a deep gap if you do JavaScript on the client and Java on the server. If developers have to do JavaScript for the client they might want to do it also on the server (with node.js). I personally do not like JavaScript and prefer Java a lot. Avatar should not be the only answer and JavaFx can not replace demands for browser clients and does not properly reach the mobile market. I would love to work on making Java a real solution for building browser and desktop clients and Dragome could be an answer for what I have started. However, I would need company or I am fighting without a chance... Best regards J?rg [1] http://cr.openjdk.java.net/~jrose/values/values-0.html [2] http://m-m-m.sourceforge.net/apidocs/net/sf/mmm/util/lang/api/Datatype.html [3] http://m-m-m.sourceforge.net/apidocs/net/sf/mmm/util/lang/api/SimpleDatatype.html [4] http://m-m-m.sourceforge.net/apidocs/net/sf/mmm/client/ui/api/package-summary.html#documentation From maurizio.cimadamore at oracle.com Fri Nov 21 11:23:33 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 21 Nov 2014 11:23:33 +0000 Subject: hg: valhalla/valhalla/langtools: Fix spcialization bugs: Message-ID: <201411211123.sALBNXSC029195@aojmv0008> Changeset: 4c0cd422af57 Author: mcimadamore Date: 2014-11-21 11:22 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4c0cd422af57 Fix spcialization bugs: * specialization of superinterfaces breaks classes in same compilation unit * clash rules miss primitive vs. reference case ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java + test/tools/javac/valhalla/typespec/Auxiliary03.java ! test/tools/javac/valhalla/typespec/Clash02.java From maurizio.cimadamore at oracle.com Mon Nov 24 13:07:27 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 24 Nov 2014 13:07:27 +0000 Subject: hg: valhalla/valhalla/langtools: More specialization fixes: Message-ID: <201411241307.sAOD7RZP013707@aojmv0008> Changeset: 0e7490390c4a Author: mcimadamore Date: 2014-11-24 13:02 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0e7490390c4a More specialization fixes: * added combinatorial destructuring of 'any' types * more refined implementation of override clashes * more refined implementation of class well-formedness w.r.t. abstract methods implementation * fix issue with AnyItem breaking Item.coerce * cleanup code (more to come) ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! 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 ! 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/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java + test/tools/javac/valhalla/typespec/Clash03.java + test/tools/javac/valhalla/typespec/Clash03.out + test/tools/javac/valhalla/typespec/Coerce.java From bitterfoxc at gmail.com Mon Nov 24 17:26:14 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Tue, 25 Nov 2014 02:26:14 +0900 Subject: Translate "State of" documents into Japanese Message-ID: Hi Brian, I want to translate "State of" documents into Japanese and expose it on the cr server. May I translate the documents on http://cr.openjdk.java.net/~briangoetz/ ? Regards, Shinya Yoshida(@bitter_fox, shinyafox) From brian.goetz at oracle.com Mon Nov 24 17:39:46 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 24 Nov 2014 12:39:46 -0500 Subject: Translate "State of" documents into Japanese In-Reply-To: References: Message-ID: <54736D62.4060801@oracle.com> That would be great. However, you may wish to consider waiting a little bit of time, as we are probably only a few weeks away from the next version of the document, and I do not want you to waste any effort. Thanks, -Brian On 11/24/2014 12:26 PM, bitter_fox wrote: > Hi Brian, > I want to translate "State of" documents into Japanese and expose it on > the cr server. > > May I translate the documents on http://cr.openjdk.java.net/~briangoetz/ ? > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) From bitterfoxc at gmail.com Mon Nov 24 17:42:48 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Tue, 25 Nov 2014 02:42:48 +0900 Subject: Translate "State of" documents into Japanese In-Reply-To: <54736D62.4060801@oracle.com> References: <54736D62.4060801@oracle.com> Message-ID: Good news! I wait the new documents! Thank you, Shinya Yoshida(@bitter_fox, shinyafox) 2014-11-25 2:39 GMT+09:00 Brian Goetz : > That would be great. However, you may wish to consider waiting a little > bit of time, as we are probably only a few weeks away from the next version > of the document, and I do not want you to waste any effort. > > Thanks, > -Brian > > > On 11/24/2014 12:26 PM, bitter_fox wrote: > >> Hi Brian, >> I want to translate "State of" documents into Japanese and expose it on >> the cr server. >> >> May I translate the documents on http://cr.openjdk.java.net/~briangoetz/ >> ? >> >> Regards, >> Shinya Yoshida(@bitter_fox, shinyafox) >> > From maurizio.cimadamore at oracle.com Mon Nov 24 18:49:21 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 24 Nov 2014 18:49:21 +0000 Subject: hg: valhalla/valhalla/langtools: More specialization cleanup: Message-ID: <201411241849.sAOInLeQ015502@aojmv0008> Changeset: 96b074860118 Author: mcimadamore Date: 2014-11-24 18:44 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/96b074860118 More specialization cleanup: * Refactored where clause code in separate class ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! 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/code/WhereClause.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.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/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java From maurizio.cimadamore at oracle.com Wed Nov 26 18:36:19 2014 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 26 Nov 2014 18:36:19 +0000 Subject: hg: valhalla/valhalla/langtools: Spurious bridges generated depending on compilation order Message-ID: <201411261836.sAQIaKUj000214@aojmv0008> Changeset: d7d120a4ef8e Author: mcimadamore Date: 2014-11-26 18:35 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/d7d120a4ef8e Spurious bridges generated depending on compilation order * change desugaring logic so that dependencies between toplevels are detected across 'implements' as well as with 'extends' clauses * change Attr to recursively attr superinterfaces (not only superclass) * change SpecializeTypes to translate superinterfaces (not only superclass) * add hack for dealing with dup local class names (working on cleaner fix) * add new redundant bridges tests * fix jdeps to unmangle dependencies on specialized symbols ! src/jdk.compiler/share/classes/com/sun/tools/classfile/Dependencies.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/CompileStates.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/tools/javac/6734819/T6734819a.out ! test/tools/javac/6734819/T6734819b.out ! test/tools/javac/6734819/T6734819c.out ! test/tools/javac/generics/bridges/BridgeHarness.java + test/tools/javac/generics/bridges/tests/TestNoSpecializedBridges01.java + test/tools/javac/generics/bridges/tests/TestNoSpecializedBridges02.java + test/tools/javac/generics/bridges/tests/TestNoSpecializedBridges03.java ! test/tools/javac/policy/test2/byfile.AB.out ! test/tools/javac/policy/test2/bytodo.AB.out