From scolebourne at joda.org  Sat Aug  1 09:32:22 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 1 Aug 2015 10:32:22 +0100
Subject: "Model 2" prototype status
In-Reply-To: <55BBD188.8020406@oracle.com>
References: <55BBD188.8020406@oracle.com>
Message-ID: <CACzrW9BzY8UyUv8D9pkCR2m_j3VddyXewzvX1VmK5==hRAD2Hw@mail.gmail.com>

Thanks for the hard work on this.

The Foo<ref> looks like a nice parallel to Foo<any> to my eyes.

Stephen
On 31 Jul 2015 20:51, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> Over the past few months, we've been building what we call our "Model 2"
> prototype, and incrementally checking it in.  It now seems stable enough
> for brave early adopters to check out.  (You'll need to build the JDK from
> source.)
>
> The previous version ("Model 1") was focused on exploring the practicality
> of specialization on the JVM architecture we have today. The compiler
> augmented classes with type metadata that otherwise would be erased away,
> which could be ignored by the JVM but consumed by the specializer.
> Specialized classes were identified using a name mangling scheme (strictly
> an expedience for prototyping, not a long-term plan.) The class loader
> recognizes the name mangling scheme and, if not found in the class path,
> the class loader invokes the specializer to generate the specialized class
> on the fly.
>
> With these many hacks (name mangling, abuse of class loaders), the result
> was mixed.  On the good side, it worked!  It was possible to write
> specializable generic classes and run them on an only-lightly-hacked JVM.
> On the bad, the resulting language had a significant usability issue -- the
> lack of a nontrivial common supertype between Foo<int> and Foo<String>.
>
> Of course, we didn't pursue this approach because we thought half-killing
> wildcards was a great idea; we pursued it because it was what worked on the
> JVM we had.  So with the Model 1 prototype in hand, we set out to see what
> could be done about providing a reasonable common supertype for all
> instantiations of an any-generic type.  (We explored a number of possible
> mechanisms and approaches, including several that are more radical than
> where we landed.  Hopefully we will find time to write up some of these
> roads-not-taken.)
>
>
> Type variables.  Type variables are divided into two categories; "ref"
> (ordinary) and "any".  Any tvars ("avars") are identified by the keyword
> "any" at their declaration site (for both generic classes and generic
> methods).  If a type variable is not modified by "any", it is implicitly an
> ordinary tvar, and treated just as in Java 8.
>
>     class Foo<T> { ... }      // T is an ordinary tvar
>     class Bar<any T> { ... }  // T is an avar
>
> Class hierarchies can be any-fied from the top down.  So it's OK to do:
>
>     class A<any T> { ... }
>     class B<T> extends A<T> { ... } // T is an ordinary tvar here
>
> but not OK to do:
>
>  class A<T> { ... }
>  class B<any T> extends A<T> { ... }
>
> The rationale for this should be clear enough; specializing a class
> entails specializing its superclasses, and if the superclass is not
> specializable, this won't work.  (Alternately, you can interpret "any T" as
> a union bound ("T extends Object | value"), and its OK to use a narrower
> bound than your supertype, but not a wider one.)
>
>
> Restrictions on avars.  Some operations that are allowed on ordinary tvars
> are not allowed on avars, such as assigning a T to an Object, assigning
> null to a T, etc.  These have not changed from Model 1.
>
>
> Wildcards.  The big change in Model 2 is the addition of support for
> wildcards over avars.  The problem with wildcards has two facets;
> translational (how do we represent a wildcard type over avars in bytecode?)
> and interpretation (Foo<?> has always been a shorthand for Foo<? extends
> Object>; on the other hand, the "intuitive" intepretation of Foo<?> is "any
> instantiation of Foo.")  The translational issues require some help from
> the JVM to solve (not yet implemented in the prototype.)  The interpretive
> issues are subtle.  While we explored trying to automatically interpret
> Foo<?> according to the common user intuition, this ran afoul of numerous
> compatibility issues.
>
> So, where we landed is: just as one must specify any-ness at the
> declaration site for a type variable, one must do the same for a wildcard
> (which is essentially declaring an anonymous type variable.) So there are
> two forms of wildcard:
>
>    Foo<ref> -- describes any reference instantiation
>    Foo<any> -- describes any instantiation
>
> and Foo<?> will be retconned to mean Foo<ref>.
>
> Raw types. Raw types have not changed at all from Java 8. As such, they
> are limited to reference instantiations.
>
> The upshot of this is we can achieve perfect source compatibility; the raw
> type Foo and the wildcard type Foo<?> continues to mean exactly what they
> always did.
>
>
> As a proof of concept, I've checked in a limited version of Streams
> (java.anyutil.Stream) that has been ported to the new model.  (Some things
> are still not hooked up yet, but the basic functionality for Stream<any T>
> works.)
>
>
> The Model 2 approach needs some (targeted) help from the VM, which is not
> yet in place.  (Specifically, protected/package methods in interfaces, and
> some help for access to private members across specializations of the same
> class.)  Until we have this, protected/package methods in anyfied classes
> will be problematic.
>
> There are also some compiler limitations, the most significant of which is
> that inner classes don't yet work as instantiations of anyfied classes; you
> have to refactor the inner class to a static named class. (There's no
> fundamental issue here, its just not done yet.)
>
> Most helpfully, the latest IntelliJ has some early support for anyfied
> generics!  (It's not perfect, but its been really helpful -- thanks guys.)
> Select language level "X" (for experimental) and it will mostly deal with
> any-tvars and any-wildcards, instead of painting your whole program red.
>
>
> We'd like to get feedback from people *using the prototype* to anyfy their
> own code.  (I'm sure people have a zillion "why did you / why didn't you"
> questions; we'll try to get to those in a writeup.)  I'll also be putting
> together a writeup on the translation strategy (though brave explorers can
> and surely will reverse engineer this with javap before this happens.)
>
>
>

From brian.goetz at oracle.com  Sat Aug  1 15:23:16 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 1 Aug 2015 11:23:16 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CACzrW9BzY8UyUv8D9pkCR2m_j3VddyXewzvX1VmK5==hRAD2Hw@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<CACzrW9BzY8UyUv8D9pkCR2m_j3VddyXewzvX1VmK5==hRAD2Hw@mail.gmail.com>
Message-ID: <55BCE464.3060705@oracle.com>

> Thanks for the hard work on this.
> The Foo<ref> looks like a nice parallel to Foo<any> to my eyes.

Thanks!

Some more on where we're going with this.  You should be able to say 
"ref" wherever you can say "any", so:

   class Foo<T> { ... }

becomes a shorthand for

   class Foo<ref T> { ... }

(just as Foo<?> has always been shorthand for Foo<? extends Object?>.)

Also, the details of translation mean that the "all any" and "all ref" 
instantiations of a type with multiple tvars are somewhat "special", so 
for a type Foo<any X, any Y, any Z>, we'll probably accept

   Foo<any>

as shorthand for Foo<any, any, any>

and

   Foo<ref>

as shorthand for Foo<ref, ref, ref>

Since the arity is fixed and known at compile time, there's no problem 
with this; there's no other logical meaning to instantiating with the 
wrong number of type args.

(Note: The compiler doesn't yet support these yet.)

The details of "partial wildcards" (Foo<int, any>) are messy and we're 
working on a story for them.

>
> Stephen
> On 31 Jul 2015 20:51, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
>> Over the past few months, we've been building what we call our "Model 2"
>> prototype, and incrementally checking it in.  It now seems stable enough
>> for brave early adopters to check out.  (You'll need to build the JDK from
>> source.)
>>
>> The previous version ("Model 1") was focused on exploring the practicality
>> of specialization on the JVM architecture we have today. The compiler
>> augmented classes with type metadata that otherwise would be erased away,
>> which could be ignored by the JVM but consumed by the specializer.
>> Specialized classes were identified using a name mangling scheme (strictly
>> an expedience for prototyping, not a long-term plan.) The class loader
>> recognizes the name mangling scheme and, if not found in the class path,
>> the class loader invokes the specializer to generate the specialized class
>> on the fly.
>>
>> With these many hacks (name mangling, abuse of class loaders), the result
>> was mixed.  On the good side, it worked!  It was possible to write
>> specializable generic classes and run them on an only-lightly-hacked JVM.
>> On the bad, the resulting language had a significant usability issue -- the
>> lack of a nontrivial common supertype between Foo<int> and Foo<String>.
>>
>> Of course, we didn't pursue this approach because we thought half-killing
>> wildcards was a great idea; we pursued it because it was what worked on the
>> JVM we had.  So with the Model 1 prototype in hand, we set out to see what
>> could be done about providing a reasonable common supertype for all
>> instantiations of an any-generic type.  (We explored a number of possible
>> mechanisms and approaches, including several that are more radical than
>> where we landed.  Hopefully we will find time to write up some of these
>> roads-not-taken.)
>>
>>
>> Type variables.  Type variables are divided into two categories; "ref"
>> (ordinary) and "any".  Any tvars ("avars") are identified by the keyword
>> "any" at their declaration site (for both generic classes and generic
>> methods).  If a type variable is not modified by "any", it is implicitly an
>> ordinary tvar, and treated just as in Java 8.
>>
>>      class Foo<T> { ... }      // T is an ordinary tvar
>>      class Bar<any T> { ... }  // T is an avar
>>
>> Class hierarchies can be any-fied from the top down.  So it's OK to do:
>>
>>      class A<any T> { ... }
>>      class B<T> extends A<T> { ... } // T is an ordinary tvar here
>>
>> but not OK to do:
>>
>>   class A<T> { ... }
>>   class B<any T> extends A<T> { ... }
>>
>> The rationale for this should be clear enough; specializing a class
>> entails specializing its superclasses, and if the superclass is not
>> specializable, this won't work.  (Alternately, you can interpret "any T" as
>> a union bound ("T extends Object | value"), and its OK to use a narrower
>> bound than your supertype, but not a wider one.)
>>
>>
>> Restrictions on avars.  Some operations that are allowed on ordinary tvars
>> are not allowed on avars, such as assigning a T to an Object, assigning
>> null to a T, etc.  These have not changed from Model 1.
>>
>>
>> Wildcards.  The big change in Model 2 is the addition of support for
>> wildcards over avars.  The problem with wildcards has two facets;
>> translational (how do we represent a wildcard type over avars in bytecode?)
>> and interpretation (Foo<?> has always been a shorthand for Foo<? extends
>> Object>; on the other hand, the "intuitive" intepretation of Foo<?> is "any
>> instantiation of Foo.")  The translational issues require some help from
>> the JVM to solve (not yet implemented in the prototype.)  The interpretive
>> issues are subtle.  While we explored trying to automatically interpret
>> Foo<?> according to the common user intuition, this ran afoul of numerous
>> compatibility issues.
>>
>> So, where we landed is: just as one must specify any-ness at the
>> declaration site for a type variable, one must do the same for a wildcard
>> (which is essentially declaring an anonymous type variable.) So there are
>> two forms of wildcard:
>>
>>     Foo<ref> -- describes any reference instantiation
>>     Foo<any> -- describes any instantiation
>>
>> and Foo<?> will be retconned to mean Foo<ref>.
>>
>> Raw types. Raw types have not changed at all from Java 8. As such, they
>> are limited to reference instantiations.
>>
>> The upshot of this is we can achieve perfect source compatibility; the raw
>> type Foo and the wildcard type Foo<?> continues to mean exactly what they
>> always did.
>>
>>
>> As a proof of concept, I've checked in a limited version of Streams
>> (java.anyutil.Stream) that has been ported to the new model.  (Some things
>> are still not hooked up yet, but the basic functionality for Stream<any T>
>> works.)
>>
>>
>> The Model 2 approach needs some (targeted) help from the VM, which is not
>> yet in place.  (Specifically, protected/package methods in interfaces, and
>> some help for access to private members across specializations of the same
>> class.)  Until we have this, protected/package methods in anyfied classes
>> will be problematic.
>>
>> There are also some compiler limitations, the most significant of which is
>> that inner classes don't yet work as instantiations of anyfied classes; you
>> have to refactor the inner class to a static named class. (There's no
>> fundamental issue here, its just not done yet.)
>>
>> Most helpfully, the latest IntelliJ has some early support for anyfied
>> generics!  (It's not perfect, but its been really helpful -- thanks guys.)
>> Select language level "X" (for experimental) and it will mostly deal with
>> any-tvars and any-wildcards, instead of painting your whole program red.
>>
>>
>> We'd like to get feedback from people *using the prototype* to anyfy their
>> own code.  (I'm sure people have a zillion "why did you / why didn't you"
>> questions; we'll try to get to those in a writeup.)  I'll also be putting
>> together a writeup on the translation strategy (though brave explorers can
>> and surely will reverse engineer this with javap before this happens.)
>>
>>
>>

From forax at univ-mlv.fr  Sat Aug  1 19:38:57 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 01 Aug 2015 19:38:57 +0000
Subject: "Model 2" prototype status
In-Reply-To: <55BBD188.8020406@oracle.com>
References: <55BBD188.8020406@oracle.com>
Message-ID: <03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>

I dislike the Foo<ref> / Foo<any> thing for several reasons.

First, i don't see why another notation is needed fo Foo<?> ? When growing a language, retrofitting things is good, providing several syntax for the same thing is wrong or at least do not help to understand the corresponding concept.

Then Foo<any> has another meaning that we may won't support now but decide to support later. Foo<any> means a Foo that can store several elements some may be Objects some may be primitives.

Your Foo<any> if it's a way to declare an anonymous type bound by any means that Foo store some elements that are either all primitives or all objects.

Given that primitive types have no subtype relathionship someting like Foo<? extends int> has no sense.
So we just need to introduce a notation for representing an anonymous type wich is a primitive or an object with no bound.
I've used Foo<*> in a previous mail but it can be any symbol other than '?'.

regards,
R?mi 



Le 31 juillet 2015 21:50:32 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>Over the past few months, we've been building what we call our "Model
>2" 
>prototype, and incrementally checking it in.  It now seems stable
>enough 
>for brave early adopters to check out.  (You'll need to build the JDK 
>from source.)
>
>The previous version ("Model 1") was focused on exploring the 
>practicality of specialization on the JVM architecture we have today. 
>The compiler augmented classes with type metadata that otherwise would 
>be erased away, which could be ignored by the JVM but consumed by the 
>specializer.  Specialized classes were identified using a name mangling
>
>scheme (strictly an expedience for prototyping, not a long-term plan.) 
>The class loader recognizes the name mangling scheme and, if not found 
>in the class path, the class loader invokes the specializer to generate
>
>the specialized class on the fly.
>
>With these many hacks (name mangling, abuse of class loaders), the 
>result was mixed.  On the good side, it worked!  It was possible to 
>write specializable generic classes and run them on an 
>only-lightly-hacked JVM.  On the bad, the resulting language had a 
>significant usability issue -- the lack of a nontrivial common
>supertype 
>between Foo<int> and Foo<String>.
>
>Of course, we didn't pursue this approach because we thought 
>half-killing wildcards was a great idea; we pursued it because it was 
>what worked on the JVM we had.  So with the Model 1 prototype in hand, 
>we set out to see what could be done about providing a reasonable
>common 
>supertype for all instantiations of an any-generic type.  (We explored
>a 
>number of possible mechanisms and approaches, including several that
>are 
>more radical than where we landed.  Hopefully we will find time to
>write 
>up some of these roads-not-taken.)
>
>
>Type variables.  Type variables are divided into two categories; "ref" 
>(ordinary) and "any".  Any tvars ("avars") are identified by the
>keyword 
>"any" at their declaration site (for both generic classes and generic 
>methods).  If a type variable is not modified by "any", it is
>implicitly 
>an ordinary tvar, and treated just as in Java 8.
>
>     class Foo<T> { ... }      // T is an ordinary tvar
>     class Bar<any T> { ... }  // T is an avar
>
>Class hierarchies can be any-fied from the top down.  So it's OK to do:
>
>     class A<any T> { ... }
>     class B<T> extends A<T> { ... } // T is an ordinary tvar here
>
>but not OK to do:
>
>  class A<T> { ... }
>  class B<any T> extends A<T> { ... }
>
>The rationale for this should be clear enough; specializing a class 
>entails specializing its superclasses, and if the superclass is not 
>specializable, this won't work.  (Alternately, you can interpret "any
>T" 
>as a union bound ("T extends Object | value"), and its OK to use a 
>narrower bound than your supertype, but not a wider one.)
>
>
>Restrictions on avars.  Some operations that are allowed on ordinary 
>tvars are not allowed on avars, such as assigning a T to an Object, 
>assigning null to a T, etc.  These have not changed from Model 1.
>
>
>Wildcards.  The big change in Model 2 is the addition of support for 
>wildcards over avars.  The problem with wildcards has two facets; 
>translational (how do we represent a wildcard type over avars in 
>bytecode?) and interpretation (Foo<?> has always been a shorthand for 
>Foo<? extends Object>; on the other hand, the "intuitive" intepretation
>
>of Foo<?> is "any instantiation of Foo.")  The translational issues 
>require some help from the JVM to solve (not yet implemented in the 
>prototype.)  The interpretive issues are subtle.  While we explored 
>trying to automatically interpret Foo<?> according to the common user 
>intuition, this ran afoul of numerous compatibility issues.
>
>So, where we landed is: just as one must specify any-ness at the 
>declaration site for a type variable, one must do the same for a 
>wildcard (which is essentially declaring an anonymous type variable.) 
>So there are two forms of wildcard:
>
>    Foo<ref> -- describes any reference instantiation
>    Foo<any> -- describes any instantiation
>
>and Foo<?> will be retconned to mean Foo<ref>.
>
>Raw types. Raw types have not changed at all from Java 8. As such, they
>
>are limited to reference instantiations.
>
>The upshot of this is we can achieve perfect source compatibility; the 
>raw type Foo and the wildcard type Foo<?> continues to mean exactly
>what 
>they always did.
>
>
>As a proof of concept, I've checked in a limited version of Streams 
>(java.anyutil.Stream) that has been ported to the new model.  (Some 
>things are still not hooked up yet, but the basic functionality for 
>Stream<any T> works.)
>
>
>The Model 2 approach needs some (targeted) help from the VM, which is 
>not yet in place.  (Specifically, protected/package methods in 
>interfaces, and some help for access to private members across 
>specializations of the same class.)  Until we have this, 
>protected/package methods in anyfied classes will be problematic.
>
>There are also some compiler limitations, the most significant of which
>
>is that inner classes don't yet work as instantiations of anyfied 
>classes; you have to refactor the inner class to a static named class. 
>(There's no fundamental issue here, its just not done yet.)
>
>Most helpfully, the latest IntelliJ has some early support for anyfied 
>generics!  (It's not perfect, but its been really helpful -- thanks 
>guys.)  Select language level "X" (for experimental) and it will mostly
>
>deal with any-tvars and any-wildcards, instead of painting your whole 
>program red.
>
>
>We'd like to get feedback from people *using the prototype* to anyfy 
>their own code.  (I'm sure people have a zillion "why did you / why 
>didn't you" questions; we'll try to get to those in a writeup.)  I'll 
>also be putting together a writeup on the translation strategy (though 
>brave explorers can and surely will reverse engineer this with javap 
>before this happens.)


From brian.goetz at oracle.com  Sat Aug  1 21:48:07 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 1 Aug 2015 17:48:07 -0400
Subject: "Model 2" prototype status
In-Reply-To: <03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
Message-ID: <55BD3E97.3020206@oracle.com>

> I dislike the Foo<ref> / Foo<any> thing for several reasons.

Not surprising.  This wasn't our first choice either.

We spent a great deal of effort investigating whether it was possible to 
re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref 
tvar, and to mean Foo<any> when the corresponding tvar is an any tvar. 
Seems obvious, right?

Several hundred hours later, the short answer is that things fall apart 
when a library is any-fied and the client is not recompiled; this would 
make any-fication a binary-incompatible change, which would be a loser. 
  So with tears in our eyes, we reluctantly concluded that we needed to 
differentiate between Foo<ref> and Foo<any>.  Once we swallowed that 
pill, many things snapped into place.  So as sad as it is to have two 
kinds of wildcard, I'm pretty sure its the right call.

You prefer another syntax?  Sure, I'm sure there are alternatives.  We 
can talk about it -- but not this year!  We have way more important 
things to work out before that comes anywhere near the top of the list.

As to bounds...  we're still working out the details of the interaction 
between value types and interfaces.  So its quite possible that Foo<any 
T extends Comparable> may in fact be meaningful.  (And if that's the 
case, primitives might join the party too.)  Or not, we're not sure yet.



From simon at ochsenreither.de  Sun Aug  2 11:17:32 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Sun, 2 Aug 2015 13:17:32 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <55BCE464.3060705@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<CACzrW9BzY8UyUv8D9pkCR2m_j3VddyXewzvX1VmK5==hRAD2Hw@mail.gmail.com>
	<55BCE464.3060705@oracle.com>
Message-ID: <486946363.105791.1438514252512.JavaMail.open-xchange@srv005.service.ps-server.net>

>  we'll probably accept Foo<any> as shorthand for Foo<any, any, any>
> and Foo<ref> as shorthand for Foo<ref, ref, ref>
>
> Since the arity is fixed and known at compile time, there's no problem
> with this; there's no other logical meaning to instantiating with the
> wrong number of type args.
 
Partially applied type constructors? Not saying that this is a concern now, but
maybe your successor in 15 years will curse you for using this syntax, when they
try to make Java 20's type system a bit more useful. :-)

From forax at univ-mlv.fr  Sun Aug  2 19:52:16 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 02 Aug 2015 19:52:16 +0000
Subject: "Model 2" prototype status
In-Reply-To: <55BD3E97.3020206@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
Message-ID: <302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>



Le 1 ao?t 2015 23:48:07 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>> I dislike the Foo<ref> / Foo<any> thing for several reasons.
>
>Not surprising.  This wasn't our first choice either.
>
>We spent a great deal of effort investigating whether it was possible
>to 
>re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref 
>tvar, and to mean Foo<any> when the corresponding tvar is an any tvar. 
>Seems obvious, right?

It's not what i propose.
Foo<any> is Foo<any>.
Foo<ref> is Foo<?> because if Foo<?> is used in a 1.10 class file it's a reified type and if Foo<?> is used in a 1.9 class the compiler considers that is not reified and disallow to cast by example a Foo<any> to a Foo<?>. Practically, in that case, a user can use something similar to a checked collection that will check at runtime that each value have the right class.

>
>Several hundred hours later, the short answer is that things fall apart
>
>when a library is any-fied and the client is not recompiled; this would
>
>make any-fication a binary-incompatible change, which would be a loser.
>
> So with tears in our eyes, we reluctantly concluded that we needed to 
>differentiate between Foo<ref> and Foo<any>.  Once we swallowed that 
>pill, many things snapped into place.  So as sad as it is to have two 
>kinds of wildcard, I'm pretty sure its the right call.
>

I understand the need of differenciating between Foo<ref> and Foo<?> but i hope that instead of having to explain that to each Java dev, we can explain that only to the few that will stumble on the issue.

>You prefer another syntax?  Sure, I'm sure there are alternatives.  We 
>can talk about it -- but not this year!  We have way more important 
>things to work out before that comes anywhere near the top of the list.

I don't care about the syntax but the one you propose doesn't help IMO.

>
>As to bounds...  we're still working out the details of the interaction
>
>between value types and interfaces.  So its quite possible that Foo<any
>
>T extends Comparable> may in fact be meaningful.  (And if that's the 
>case, primitives might join the party too.)  Or not, we're not sure
>yet.

yes, forget the interfaces,
i suppose that it's not a big deal to not try to support them until you want to introduce value types in a later release :(

R?mi 



From timo.kinnunen at gmail.com  Sun Aug  2 20:55:56 2015
From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=)
Date: Sun, 2 Aug 2015 20:55:56 +0000
Subject: =?utf-8?Q?Re:_"Model_2"_prototype_status?=
In-Reply-To: <302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>,
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
Message-ID: <55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>

Hi, 




Re: ?I don't care about the syntax but the one you propose doesn't help IMO.?




I have to agree. You really get a sense that there is no overall design behind this syntax backing it up. 




For example, my current source of confusion is whether A<any T> is to be interpreted as A<ref T | any T | null> or as A<ref T | any T | !(null)>. (A note on the syntax being used: the presence  or absence of the nulltype amongst the bounds is to be interpreted literally.)




Seeing ?Alternately, you can interpret "any T" as a union bound ("T extends Object | value")? suggests it?s the first interpretation that?s correct but then seeing ? Some operations that are allowed on ordinary tvars are not allowed on avars, such as assigning a T to an Object, assigning null to a T, etc.? suggests the correct interpretation should be the latter.


A properly designed syntax where such semantics can be expressed in a natural way will be helpful to have, one year from now. Would be much more helpful to have it right now though, IMHO?


















-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: R?mi Forax
Sent: ?Sunday?, ?August? ?2?, ?2015 ?21?:?52
To: Brian Goetz, valhalla-dev at openjdk.java.net







Le 1 ao?t 2015 23:48:07 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>> I dislike the Foo<ref> / Foo<any> thing for several reasons.
>
>Not surprising.  This wasn't our first choice either.
>
>We spent a great deal of effort investigating whether it was possible
>to 
>re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref 
>tvar, and to mean Foo<any> when the corresponding tvar is an any tvar. 
>Seems obvious, right?

It's not what i propose.
Foo<any> is Foo<any>.
Foo<ref> is Foo<?> because if Foo<?> is used in a 1.10 class file it's a reified type and if Foo<?> is used in a 1.9 class the compiler considers that is not reified and disallow to cast by example a Foo<any> to a Foo<?>. Practically, in that case, a user can use something similar to a checked collection that will check at runtime that each value have the right class.

>
>Several hundred hours later, the short answer is that things fall apart
>
>when a library is any-fied and the client is not recompiled; this would
>
>make any-fication a binary-incompatible change, which would be a loser.
>
> So with tears in our eyes, we reluctantly concluded that we needed to 
>differentiate between Foo<ref> and Foo<any>.  Once we swallowed that 
>pill, many things snapped into place.  So as sad as it is to have two 
>kinds of wildcard, I'm pretty sure its the right call.
>

I understand the need of differenciating between Foo<ref> and Foo<?> but i hope that instead of having to explain that to each Java dev, we can explain that only to the few that will stumble on the issue.

>You prefer another syntax?  Sure, I'm sure there are alternatives.  We 
>can talk about it -- but not this year!  We have way more important 
>things to work out before that comes anywhere near the top of the list.

I don't care about the syntax but the one you propose doesn't help IMO.

>
>As to bounds...  we're still working out the details of the interaction
>
>between value types and interfaces.  So its quite possible that Foo<any
>
>T extends Comparable> may in fact be meaningful.  (And if that's the 
>case, primitives might join the party too.)  Or not, we're not sure
>yet.

yes, forget the interfaces,
i suppose that it's not a big deal to not try to support them until you want to introduce value types in a later release :(

R?mi

From mikeb01 at gmail.com  Mon Aug  3 01:53:02 2015
From: mikeb01 at gmail.com (Michael Barker)
Date: Mon, 3 Aug 2015 13:53:02 +1200
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
Message-ID: <CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>

Hi,

Having played with it a bit more, I can get the bound check removed under
one specific arrangement of the code, the following is for the
RingBufferFields.elementAt:

1)  return (E) entries[((int) sequence) & (entries.length - 1)];

This works and I get the pattern mentioned Paul's example.  There is a
drawback to implementing it this way, details below.

2)  return (E) entries[(int) sequence & (entries.length - 1)];

Note the position of the brackets.  In this case entries.length is being
promoted to a long before applying the mask, then being cast down to an
int, which seems to trip up the compiler.

3)  return (E) entries[((int) sequence) & indexMask];  // indexMask is a
final field of value entries.length - 1

I suspect this is because the compiler can't assume that final fields are
actually final.

4)  return (E) entries[BUFFER_PAD + (((int) sequence) & (entries.length -
((BUFFER_PAD * 2) + 1)))];

I'm guessing it gets just too complex for the compiler to figure our that
the resulting value will be less that entries.length.

One of the niggles with approach #1, is that I need to reference
entries.length at the call site and can't use a separate field to store the
value.  This can cause issue in a concurrent ring-buffer-like structures as
the array length can end up sharing a cache line with the array itself.  So
if a producer thread writes into one of the first 15 array slots (worst
case), the whole line including the part containing the length field will
be invalid on the consumer's core resulting in an additional cache miss in
certain cases.  This is probably less of an issue for the default set up of
the disruptor as we don't actually replace the references inside of the
entries array, but a number of fast queue implementations would suffer.
The developer is caught having to make a trade-off between reducing false
sharing and removing bounds checking.

Mike.


On 1 August 2015 at 00:18, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 31 Jul 2015, at 07:43, Michael Barker <mikeb01 at gmail.com> wrote:
>
> > Hi Paul,
> >
> > I've had a look at the patch that you mentioned and AFAICT it doesn't
> seem to be able to eliminate the bounds check, even if I remove the array
> padding.  Just to confirm my analysis the assembler around the aaload
> instruction looks like:
> >
> > 0x00007f627d6b3aea: cmp    %ebx,%edx
> > 0x00007f627d6b3aec: jae    0x00007f627d6b3e0c
> > 0x00007f627d6b3af2: mov    %r8,%r13
> > 0x00007f627d6b3af5: mov    %r11d,%r8d
> > 0x00007f627d6b3af8: mov    0x10(%rax,%rdx,4),%r11d  ;*aaload
> >
> > I'm guessing that the cmp/jae pair is the bounds check?
> >
>
> Yes, i am assuming that is generated code of RingBuffer.elementAt (aaload)
> and not MultiProducerSequencer. I suspect the padding is throwing the
> compiler off the scent (it does not know that indexMask is less than
> entries.length - BUFFER_INDEX).
>
> For an array access such as:
>
>   int j = i & (a.length - 1);
>   X x = a[j];
>
> I would expect to observe something like:
>
>   test   %edi,%edi
>   jbe    ?
>
> The bound check should get strength reduced to checking if the array
> length is zero, and i would expect such a test to be hoisted out of any
> loop (and get folded into another dominating array length check, if any).
>
> Here is an example, given this benchmark method:
>
> @Benchmark
> public int relaxed_r_aa() {
>     Value[] _receiver = receiver;
>     int sum = 0;
>     for (int i = start; i < end; i++) {
>         int j = i & (_receiver.length - 1);
>         sum += _receiver[j].i;
>     }
>     return sum;
> }
>
> Without the patch the following code is generated (when loop unrolling is
> switched off):
>
> : mov    0xc(%r12,%rbx,8),%r9d  ;*arraylength
> : mov    %r9d,%r11d
> : dec    %r11d
> : lea    (%r12,%rbx,8),%rcx
> : xor    %eax,%eax          ;*iload_3
>
> <loop>: mov    %r11d,%ebp
> : and    %r10d,%ebp         ;*iand
> : cmp    %r9d,%ebp
> : jae    <bounds-fail>
> : mov    0x10(%rcx,%rbp,4),%edi  ;*aaload
> : add    0xc(%r12,%rdi,8),%eax  ;*iadd
> : inc    %r10d              ;*iinc
> : cmp    %r8d,%r10d
> : jl     <loop>  ;*if_icmpge
>
>
> When the patch is applied the following code is generated:
>
> : mov    0xc(%r12,%rbp,8),%r9d  ;*arraylength
> : test   %r9d,%r9d
> : jbe    <bounds-fail>
> : dec    %r9d
> : lea    (%r12,%rbp,8),%r8
> : data32 nopw 0x0(%rax,%rax,1)
> : data32 data32 xchg %ax,%ax  ;*iload_3
>
> <loop>: mov    %r9d,%ebx
> : and    %r11d,%ebx
> : mov    0x10(%r8,%rbx,4),%ebx  ;*aaload
> : add    0xc(%r12,%rbx,8),%eax  ;*iadd
> : inc    %r11d              ;*iinc
> : cmp    %r10d,%r11d
> : jl     <loop>  ;*if_icmpge
>
>
>
> > A quick note on the patch, it merged, but didn't compile.  There seemed
> to be a signature change on the signature of ConINode::make, so I changed
> line 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);' to
> 'return ConINode::make(1);'.  That let it compile, but I don't really
> understand the code so I'm not sure if it is semantically correct.
> >
>
> Oops sorry about that, i uploaded a new revision of the patch the same fix
> that you applied.
>
> Paul.
>
>

From vitalyd at gmail.com  Mon Aug  3 02:52:58 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Sun, 2 Aug 2015 22:52:58 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
Message-ID: <CAHjP37F3tWBBJC0xdV5UHca5BLMXTc4=obDzH-nPb3DDxXceLA@mail.gmail.com>

I think any approach that requires reading the length of an array, whether
user or compiler inserted, is going to run afoul of possible false sharing;
only approach #3 would work since the mask field could be isolated to its
own cacheline.

sent from my phone
On Aug 2, 2015 9:54 PM, "Michael Barker" <mikeb01 at gmail.com> wrote:

> Hi,
>
> Having played with it a bit more, I can get the bound check removed under
> one specific arrangement of the code, the following is for the
> RingBufferFields.elementAt:
>
> 1)  return (E) entries[((int) sequence) & (entries.length - 1)];
>
> This works and I get the pattern mentioned Paul's example.  There is a
> drawback to implementing it this way, details below.
>
> 2)  return (E) entries[(int) sequence & (entries.length - 1)];
>
> Note the position of the brackets.  In this case entries.length is being
> promoted to a long before applying the mask, then being cast down to an
> int, which seems to trip up the compiler.
>
> 3)  return (E) entries[((int) sequence) & indexMask];  // indexMask is a
> final field of value entries.length - 1
>
> I suspect this is because the compiler can't assume that final fields are
> actually final.
>
> 4)  return (E) entries[BUFFER_PAD + (((int) sequence) & (entries.length -
> ((BUFFER_PAD * 2) + 1)))];
>
> I'm guessing it gets just too complex for the compiler to figure our that
> the resulting value will be less that entries.length.
>
> One of the niggles with approach #1, is that I need to reference
> entries.length at the call site and can't use a separate field to store the
> value.  This can cause issue in a concurrent ring-buffer-like structures as
> the array length can end up sharing a cache line with the array itself.  So
> if a producer thread writes into one of the first 15 array slots (worst
> case), the whole line including the part containing the length field will
> be invalid on the consumer's core resulting in an additional cache miss in
> certain cases.  This is probably less of an issue for the default set up of
> the disruptor as we don't actually replace the references inside of the
> entries array, but a number of fast queue implementations would suffer.
> The developer is caught having to make a trade-off between reducing false
> sharing and removing bounds checking.
>
> Mike.
>
>
> On 1 August 2015 at 00:18, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
> >
> > On 31 Jul 2015, at 07:43, Michael Barker <mikeb01 at gmail.com> wrote:
> >
> > > Hi Paul,
> > >
> > > I've had a look at the patch that you mentioned and AFAICT it doesn't
> > seem to be able to eliminate the bounds check, even if I remove the array
> > padding.  Just to confirm my analysis the assembler around the aaload
> > instruction looks like:
> > >
> > > 0x00007f627d6b3aea: cmp    %ebx,%edx
> > > 0x00007f627d6b3aec: jae    0x00007f627d6b3e0c
> > > 0x00007f627d6b3af2: mov    %r8,%r13
> > > 0x00007f627d6b3af5: mov    %r11d,%r8d
> > > 0x00007f627d6b3af8: mov    0x10(%rax,%rdx,4),%r11d  ;*aaload
> > >
> > > I'm guessing that the cmp/jae pair is the bounds check?
> > >
> >
> > Yes, i am assuming that is generated code of RingBuffer.elementAt
> (aaload)
> > and not MultiProducerSequencer. I suspect the padding is throwing the
> > compiler off the scent (it does not know that indexMask is less than
> > entries.length - BUFFER_INDEX).
> >
> > For an array access such as:
> >
> >   int j = i & (a.length - 1);
> >   X x = a[j];
> >
> > I would expect to observe something like:
> >
> >   test   %edi,%edi
> >   jbe    ?
> >
> > The bound check should get strength reduced to checking if the array
> > length is zero, and i would expect such a test to be hoisted out of any
> > loop (and get folded into another dominating array length check, if any).
> >
> > Here is an example, given this benchmark method:
> >
> > @Benchmark
> > public int relaxed_r_aa() {
> >     Value[] _receiver = receiver;
> >     int sum = 0;
> >     for (int i = start; i < end; i++) {
> >         int j = i & (_receiver.length - 1);
> >         sum += _receiver[j].i;
> >     }
> >     return sum;
> > }
> >
> > Without the patch the following code is generated (when loop unrolling is
> > switched off):
> >
> > : mov    0xc(%r12,%rbx,8),%r9d  ;*arraylength
> > : mov    %r9d,%r11d
> > : dec    %r11d
> > : lea    (%r12,%rbx,8),%rcx
> > : xor    %eax,%eax          ;*iload_3
> >
> > <loop>: mov    %r11d,%ebp
> > : and    %r10d,%ebp         ;*iand
> > : cmp    %r9d,%ebp
> > : jae    <bounds-fail>
> > : mov    0x10(%rcx,%rbp,4),%edi  ;*aaload
> > : add    0xc(%r12,%rdi,8),%eax  ;*iadd
> > : inc    %r10d              ;*iinc
> > : cmp    %r8d,%r10d
> > : jl     <loop>  ;*if_icmpge
> >
> >
> > When the patch is applied the following code is generated:
> >
> > : mov    0xc(%r12,%rbp,8),%r9d  ;*arraylength
> > : test   %r9d,%r9d
> > : jbe    <bounds-fail>
> > : dec    %r9d
> > : lea    (%r12,%rbp,8),%r8
> > : data32 nopw 0x0(%rax,%rax,1)
> > : data32 data32 xchg %ax,%ax  ;*iload_3
> >
> > <loop>: mov    %r9d,%ebx
> > : and    %r11d,%ebx
> > : mov    0x10(%r8,%rbx,4),%ebx  ;*aaload
> > : add    0xc(%r12,%rbx,8),%eax  ;*iadd
> > : inc    %r11d              ;*iinc
> > : cmp    %r10d,%r11d
> > : jl     <loop>  ;*if_icmpge
> >
> >
> >
> > > A quick note on the patch, it merged, but didn't compile.  There seemed
> > to be a signature change on the signature of ConINode::make, so I changed
> > line 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);' to
> > 'return ConINode::make(1);'.  That let it compile, but I don't really
> > understand the code so I'm not sure if it is semantically correct.
> > >
> >
> > Oops sorry about that, i uploaded a new revision of the patch the same
> fix
> > that you applied.
> >
> > Paul.
> >
> >
>

From martijnverburg at gmail.com  Mon Aug  3 08:38:10 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 3 Aug 2015 09:38:10 +0100
Subject: "Model 2" prototype status
In-Reply-To: <55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
Message-ID: <CAP7YuARqqfOSEewhKgOO_-nr6B29y318FoxKcXsMQqvZuBxkHQ@mail.gmail.com>

Hi Timo/all,

I appreciate that a particular syntax can make it more difficult to
understand the semantics of something as complex as this proposal (I had to
stop myself from commenting on parts I didn't like), but the assumption
that 'You really get a sense that there is no overall design behind this
syntax backing it up.' is (to be blunt) not helpful. Brian's original email
clearly showed a lot of time, effort and design has gone into this proposal
and I'm personally happy that we get an early look at these things so we
can find holes in the semantics :-).  We can argue/fix/review Syntax easily
towards the end, altering javac for syntax isn't going to be the hard part.

I'd encourage people to spend a good length of time exploring this
proposal, try samples out on their own code, think long and hard about the
underlying interactions between Generics (wildcards in particular), the
proposed concept of Any, how primitives might play into this etc. This is
actually some pretty good intellectual fodder for a series of brown bag
sessions with colleagues (I'm itching for whiteboard markers right now). As
a reminder: http://openjdk.java.net/projects/valhalla/ outlines some of the
suggested participation/feedback which will be most helpful.



Cheers,
Martijn

On 2 August 2015 at 21:55, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:

> Hi,
>
>
>
>
> Re: ?I don't care about the syntax but the one you propose doesn't help
> IMO.?
>
>
>
>
> I have to agree. You really get a sense that there is no overall design
> behind this syntax backing it up.
>
>
>
>
> For example, my current source of confusion is whether A<any T> is to be
> interpreted as A<ref T | any T | null> or as A<ref T | any T | !(null)>. (A
> note on the syntax being used: the presence  or absence of the nulltype
> amongst the bounds is to be interpreted literally.)
>
>
>
>
> Seeing ?Alternately, you can interpret "any T" as a union bound ("T
> extends Object | value")? suggests it?s the first interpretation that?s
> correct but then seeing ? Some operations that are allowed on ordinary
> tvars are not allowed on avars, such as assigning a T to an Object,
> assigning null to a T, etc.? suggests the correct interpretation should be
> the latter.
>
>
> A properly designed syntax where such semantics can be expressed in a
> natural way will be helpful to have, one year from now. Would be much more
> helpful to have it right now though, IMHO?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
>
>
>
>
> From: R?mi Forax
> Sent: ?Sunday?, ?August? ?2?, ?2015 ?21?:?52
> To: Brian Goetz, valhalla-dev at openjdk.java.net
>
>
>
>
>
>
>
> Le 1 ao?t 2015 23:48:07 CEST, Brian Goetz <brian.goetz at oracle.com> a
> ?crit :
> >> I dislike the Foo<ref> / Foo<any> thing for several reasons.
> >
> >Not surprising.  This wasn't our first choice either.
> >
> >We spent a great deal of effort investigating whether it was possible
> >to
> >re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
> >tvar, and to mean Foo<any> when the corresponding tvar is an any tvar.
> >Seems obvious, right?
>
> It's not what i propose.
> Foo<any> is Foo<any>.
> Foo<ref> is Foo<?> because if Foo<?> is used in a 1.10 class file it's a
> reified type and if Foo<?> is used in a 1.9 class the compiler considers
> that is not reified and disallow to cast by example a Foo<any> to a Foo<?>.
> Practically, in that case, a user can use something similar to a checked
> collection that will check at runtime that each value have the right class.
>
> >
> >Several hundred hours later, the short answer is that things fall apart
> >
> >when a library is any-fied and the client is not recompiled; this would
> >
> >make any-fication a binary-incompatible change, which would be a loser.
> >
> > So with tears in our eyes, we reluctantly concluded that we needed to
> >differentiate between Foo<ref> and Foo<any>.  Once we swallowed that
> >pill, many things snapped into place.  So as sad as it is to have two
> >kinds of wildcard, I'm pretty sure its the right call.
> >
>
> I understand the need of differenciating between Foo<ref> and Foo<?> but i
> hope that instead of having to explain that to each Java dev, we can
> explain that only to the few that will stumble on the issue.
>
> >You prefer another syntax?  Sure, I'm sure there are alternatives.  We
> >can talk about it -- but not this year!  We have way more important
> >things to work out before that comes anywhere near the top of the list.
>
> I don't care about the syntax but the one you propose doesn't help IMO.
>
> >
> >As to bounds...  we're still working out the details of the interaction
> >
> >between value types and interfaces.  So its quite possible that Foo<any
> >
> >T extends Comparable> may in fact be meaningful.  (And if that's the
> >case, primitives might join the party too.)  Or not, we're not sure
> >yet.
>
> yes, forget the interfaces,
> i suppose that it's not a big deal to not try to support them until you
> want to introduce value types in a later release :(
>
> R?mi

From gavin.bierman at oracle.com  Mon Aug  3 13:43:18 2015
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 3 Aug 2015 14:43:18 +0100
Subject: "Model 2" prototype status
In-Reply-To: <55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
Message-ID: <D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>

Hi Timo,

> On 2 Aug 2015, at 21:55, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
> 
> Hi, 
> 
> Re: ?I don't care about the syntax but the one you propose doesn't help IMO.?
> 
> I have to agree. You really get a sense that there is no overall design behind this syntax backing it up. 
> 
> For example, my current source of confusion is whether A<any T> is to be interpreted as A<ref T | any T | null> or as A<ref T | any T | !(null)>. (A note on the syntax being used: the presence  or absence of the nulltype amongst the bounds is to be interpreted literally.)
> 
> Seeing ?Alternately, you can interpret "any T" as a union bound ("T extends Object | value")? suggests it?s the first interpretation that?s correct but then seeing ? Some operations that are allowed on ordinary tvars are not allowed on avars, such as assigning a T to an Object, assigning null to a T, etc.? suggests the correct interpretation should be the latter.
> 
> 
> A properly designed syntax where such semantics can be expressed in a natural way will be helpful to have, one year from now. Would be much more helpful to have it right now though, IMHO?

As I?m the semantics guy on the design team your request for semantics got my attention :-) (Plus I?d like to reassure you that there are hundreds of hours of thinking about the design so far; and many more to come!)

Here?s a semantic take on what?s going on: A type is a set of values. In Java when declaring variables we are used to declaring their type, e.g. `Bar x`. A _sort_ is a set of types. Currently in Java when declaring type variables we do not declare their type/sort; it?s implicit, and is the set of all reference types. (Some languages do let you define the sorts of type variables, e.g. Haskell.) Of course we can constraint the set further with bounds, but morally type variables have a type/sort.

In Valhalla we will be in the world where some type variables will range over all reference types, and some over other sorts. It?s this 'other sorts' stuff that is new. In our experiments, we have identified three useful sorts: (i) `any` the sort containing all types, (ii) `ref` the sort containing all reference types (currently, the only sort denotable in Java), and (iii) `val` the sort containing all value types (currently the eight primitive types, but we are also experimenting with supporting user-defined value classes). We currently adopt a similar syntax for sort declarations as for type declarations, e.g. `ref X`, although other syntax choices could be taken from other languages, e.g. `X::ref`. We?re trying not to get too bogged down with syntax right now, but the idea should be clear.

Placing a sort on a type variable in, for example, a class declaration can have consequences in the declaration body. If you declare a class `Pop<any T>` you are declaring it *for all* instantiations of T, including primitives. Hence in the body of declaration, you shouldn?t be able to assign null to an instance of the type variable, for example. It breaks the contract in the declaration. This is no different to Java 8, where we check in the body that we respect the bounds contract on type variables. 

Given that wildcards are a form of existential type, corresponding to the three sorts are three forms of wildcards: (i) `Foo<any>` which denotes any type instantiation of `Foo`; (ii) `Foo<ref>` which denotes a reference type instantiation of `Foo` (this is currently written `Foo<?>` in Java); and (iii) `Foo<val>` which denotes a value type instantiation of `Foo`. Again, our syntax is preliminary; we could write these as `Foo<any ?>`, `Foo<ref ?>` and `Foo<val ?>`, for example.

[BTW: Currently the prototype doesn?t support the `val` sort, but I wanted to add it to help you see what we?re up to.]

I?m working on a more formal definition of the design and the translation strategy, which I can share with you when it?s ready, if you like. (It?ll look something like this: http://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf <http://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf>)

Hope this helps,
Gavin

From brian.goetz at oracle.com  Mon Aug  3 15:00:04 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 3 Aug 2015 11:00:04 -0400
Subject: "Model 2" prototype status
In-Reply-To: <D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
Message-ID: <55BF81F4.7010400@oracle.com>

> Placing a sort on a type variable in, for example, a class declaration
> can have consequences in the declaration body. If you declare a class
> `Pop<any T>` you are declaring it *for all* instantiations of T,
> including primitives. Hence in the body of declaration, you shouldn?t be
> able to assign null to an instance of the type variable, for example. It
> breaks the contract in the declaration. This is no different to Java 8,
> where we check in the body that we respect the bounds contract on type
> variables.

Don't forget nullability is just an example here of the category of 
things that "classical" generics allow based on the assumption that type 
variables only quantify over reference types.

A similar restriction is that you can't use an avar as the lock object 
for a synchronized block.  Why?  Because the lock object has to be an 
_Object_.  And if T is an any-var, it might be an int -- which means you 
can't use it as a lock object.

Same for:
  - Object methods that are not going to be lifted to values (it seems 
likely that equals/hashCode/toString/getClass will find their way to 
values, and that wait/notify will not.  (But note this has little to do 
with anyfied generics directly -- this has to do with the properties of 
value types when we add them to the type system.  Of course, the goal 
here is that generics interact nicely with value types, but the two are 
separate problems.)
  - Assumptions that T[] <: Object[]; this is true for reference T but 
not for value T.

Again, these restrictions are simply consequences of quantifying over a 
heterogeneous sort of types; if there's at least one type (e.g., int) in 
the sort "any T", then things like "synchronized (T)" or "T = null" 
can't be allowed because we can't be confident they mean something.

This is no different from restrictions we impose now.  For example:

class Foo<T> {
     T t;

     ... I can call t.toString() ...

     ... But I can't call t.intValue() because I have no reason to 
believe this method exists on T ...
}


From scolebourne at joda.org  Mon Aug  3 17:45:18 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 3 Aug 2015 18:45:18 +0100
Subject: "Model 2" prototype status
In-Reply-To: <55BF81F4.7010400@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com>
Message-ID: <CACzrW9CWO5ydLFiubwhY0zRP5m8nPHHwjwB9QnjxbT1=uTQbXg@mail.gmail.com>

On 3 August 2015 at 16:00, Brian Goetz <brian.goetz at oracle.com> wrote:
> Don't forget nullability is just an example here of the category of things
> that "classical" generics allow based on the assumption that type variables
> only quantify over reference types.

While true, I think it is fair to say it is likely to be the key one
that affects developers. Relatively few would call synchronized on an
arbitrary T, or wait(), or notify(). Whereas, assuming that T could be
null and setting it to null is a pretty common assumption (whether for
good or bad). That is why nulls will be an area I'll be watching
closely as the prototype develops, to attempt to tease out if the
right choice/balance/tradeoff is being made.

Stephen

From smarter3 at gmail.com  Mon Aug  3 19:09:56 2015
From: smarter3 at gmail.com (Guillaume Martres)
Date: Mon, 03 Aug 2015 21:09:56 +0200
Subject: "Model 2" prototype status
In-Reply-To: <CACzrW9CWO5ydLFiubwhY0zRP5m8nPHHwjwB9QnjxbT1=uTQbXg@mail.gmail.com>
References: <55BBD188.8020406@oracle.com> <55BF81F4.7010400@oracle.com>
	<CACzrW9CWO5ydLFiubwhY0zRP5m8nPHHwjwB9QnjxbT1=uTQbXg@mail.gmail.com>
Message-ID: <3616079.OSuzDJuO7J@marvin>

On Monday 03 August 2015 18:45:18 Stephen Colebourne wrote:
> On 3 August 2015 at 16:00, Brian Goetz <brian.goetz at oracle.com> wrote:
> > Don't forget nullability is just an example here of the category of things
> > that "classical" generics allow based on the assumption that type
> > variables
> > only quantify over reference types.
> 
> While true, I think it is fair to say it is likely to be the key one
> that affects developers. Relatively few would call synchronized on an
> arbitrary T, or wait(), or notify(). Whereas, assuming that T could be
> null and setting it to null is a pretty common assumption (whether for
> good or bad). That is why nulls will be an area I'll be watching
> closely as the prototype develops, to attempt to tease out if the
> right choice/balance/tradeoff is being made.
> 
> Stephen

Right now, the prototype allows you to write "T.default" to get a value of 
type T which is null for references and 0 for value types.

From timo.kinnunen at gmail.com  Mon Aug  3 23:38:55 2015
From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=)
Date: Mon, 3 Aug 2015 23:38:55 +0000
Subject: =?utf-8?Q?Re:_"Model_2"_prototype_status?=
In-Reply-To: <D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>,
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
Message-ID: <55c031b7.47d6b40a.0e2c.0159@mx.google.com>

Hi, 


Thank you very much for writing up this detailed description! Indeed, it was the bit of syntax for <val T> that I was missing. With that in place, then using my syntax:


class A<any T>  {} 

== class A<T extends Object | null | val T> {} 

== class A<ref T | null | val T> {}

and 

class B<ref T | null> extends A<T> {} // is valid




class C<val T> extends A<T> {} // is valid

class D<any T> extends B<T> {} // not valid


And now things make a lot more sense.



The reason I?m keeping the special null type from ?4.1 as a separate bound rather than having it folded inside <ref T> is that it lets the other possible combinations of bounds to have useful semantics attached to them. A <ref T> (the null type of ?4.1 is specifically not included in the bounds!) would be the target type of primitive boxing conversion, and <val T | null> would be the target type of a value boxing conversion. Once these can be expressed, expressing the conversions itself becomes possible too.


Those tools available, it would now be possible to do better than treating the union type <ref T | null | val T> as the intersection type <ref T & null & val T> within the default implementation. Might as well, as this intersection type is usually empty anyway. To do better any needed conversion methods can be included as abstract stud methods to be compiled against.


Alas, I don?t get the impression that the design of the syntax has being able to express and explore semantics like these that can come up during the design of value types as one of its main goals. Instead the goals seem have more to do with the prototype being able to demonstrate which road it?s currently taking. The result of this is that it makes discussing the ?roads that weren't taken? quite difficult and independently verifying them later almost impossible.





-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Gavin Bierman
Sent: ?Monday?, ?August? ?3?, ?2015 ?15?:?43
To: Timo Kinnunen
Cc: R?mi Forax, Brian Goetz, valhalla-dev at openjdk.java.net




Hi Timo,


On 2 Aug 2015, at 21:55, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:

Hi, 

Re: ?I don't care about the syntax but the one you propose doesn't help IMO.?

I have to agree. You really get a sense that there is no overall design behind this syntax backing it up. 

For example, my current source of confusion is whether A<any T> is to be interpreted as A<ref T | any T | null> or as A<ref T | any T | !(null)>. (A note on the syntax being used: the presence  or absence of the nulltype amongst the bounds is to be interpreted literally.)

Seeing ?Alternately, you can interpret "any T" as a union bound ("T extends Object | value")? suggests it?s the first interpretation that?s correct but then seeing ? Some operations that are allowed on ordinary tvars are not allowed on avars, such as assigning a T to an Object, assigning null to a T, etc.? suggests the correct interpretation should be the latter.


A properly designed syntax where such semantics can be expressed in a natural way will be helpful to have, one year from now. Would be much more helpful to have it right now though, IMHO?


As I?m the semantics guy on the design team your request for semantics got my attention :-) (Plus I?d like to reassure you that there are hundreds of hours of thinking about the design so far; and many more to come!)

Here?s a semantic take on what?s going on: A type is a set of values. In Java when declaring variables we are used to declaring their type, e.g. `Bar x`. A _sort_ is a set of types. Currently in Java when declaring type variables we do not declare their type/sort; it?s implicit, and is the set of all reference types. (Some languages do let you define the sorts of type variables, e.g. Haskell.) Of course we can constraint the set further with bounds, but morally type variables have a type/sort.

In Valhalla we will be in the world where some type variables will range over all reference types, and some over other sorts. It?s this 'other sorts' stuff that is new. In our experiments, we have identified three useful sorts: (i) `any` the sort containing all types, (ii) `ref` the sort containing all reference types (currently, the only sort denotable in Java), and (iii) `val` the sort containing all value types (currently the eight primitive types, but we are also experimenting with supporting user-defined value classes). We currently adopt a similar syntax for sort declarations as for type declarations, e.g. `ref X`, although other syntax choices could be taken from other languages, e.g. `X::ref`. We?re trying not to get too bogged down with syntax right now, but the idea should be clear.

Placing a sort on a type variable in, for example, a class declaration can have consequences in the declaration body. If you declare a class `Pop<any T>` you are declaring it *for all* instantiations of T, including primitives. Hence in the body of declaration, you shouldn?t be able to assign null to an instance of the type variable, for example. It breaks the contract in the declaration. This is no different to Java 8, where we check in the body that we respect the bounds contract on type variables. 

Given that wildcards are a form of existential type, corresponding to the three sorts are three forms of wildcards: (i) `Foo<any>` which denotes any type instantiation of `Foo`; (ii) `Foo<ref>` which denotes a reference type instantiation of `Foo` (this is currently written `Foo<?>` in Java); and (iii) `Foo<val>` which denotes a value type instantiation of `Foo`. Again, our syntax is preliminary; we could write these as `Foo<any ?>`, `Foo<ref ?>` and `Foo<val ?>`, for example.

[BTW: Currently the prototype doesn?t support the `val` sort, but I wanted to add it to help you see what we?re up to.]

I?m working on a more formal definition of the design and the translation strategy, which I can share with you when it?s ready, if you like. (It?ll look something like this: http://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf)

Hope this helps,
Gavin

From kervin at sludev.com  Tue Aug  4 14:47:27 2015
From: kervin at sludev.com (Kervin Pierre)
Date: Tue, 4 Aug 2015 14:47:27 +0000
Subject: "Model 2" prototype status
In-Reply-To: <55BF81F4.7010400@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com>
Message-ID: <1438699645.4725.33.camel@sludev.com>

Thanks a Gavin, Brian for the very clear definition of the problem
( along with all the time spent solving it ).

Simple question... I can't help to think ( although I may be incorrect )
that a massive amount of this issue goes away ( for new programs ) with
a unified object/valueType hierarchy and availability of autoboxing
tweaks.

1. A sort that matches primitives but instructs the compiler to box them
to value types.  This would not replace the sort that matches but does
not box, e.g. 'anyObject' and 'any' respectively.  Also 'anyObject'
would match 'ref'.

2. Value type hierarchy base object appearing to the compiler has
Object.

Some popular languages seem to have success with this approach.  And at
least on the surface it seems to solve nullability and and host of other
API issues that have been discussed.

More out of curiosity than anything else, is there anything inherently
wrong/broken with the above approach?

Best regards,
Kervin

On Mon, 2015-08-03 at 11:00 -0400, Brian Goetz wrote:
> > Placing a sort on a type variable in, for example, a class declaration
> > can have consequences in the declaration body. If you declare a class
> > `Pop<any T>` you are declaring it *for all* instantiations of T,
> > including primitives. Hence in the body of declaration, you shouldn?t be
> > able to assign null to an instance of the type variable, for example. It
> > breaks the contract in the declaration. This is no different to Java 8,
> > where we check in the body that we respect the bounds contract on type
> > variables.
> 
> Don't forget nullability is just an example here of the category of 
> things that "classical" generics allow based on the assumption that type 
> variables only quantify over reference types.
> 
> A similar restriction is that you can't use an avar as the lock object 
> for a synchronized block.  Why?  Because the lock object has to be an 
> _Object_.  And if T is an any-var, it might be an int -- which means you 
> can't use it as a lock object.
> 
> Same for:
>   - Object methods that are not going to be lifted to values (it seems 
> likely that equals/hashCode/toString/getClass will find their way to 
> values, and that wait/notify will not.  (But note this has little to do 
> with anyfied generics directly -- this has to do with the properties of 
> value types when we add them to the type system.  Of course, the goal 
> here is that generics interact nicely with value types, but the two are 
> separate problems.)
>   - Assumptions that T[] <: Object[]; this is true for reference T but 
> not for value T.
> 
> Again, these restrictions are simply consequences of quantifying over a 
> heterogeneous sort of types; if there's at least one type (e.g., int) in 
> the sort "any T", then things like "synchronized (T)" or "T = null" 
> can't be allowed because we can't be confident they mean something.
> 
> This is no different from restrictions we impose now.  For example:
> 
> class Foo<T> {
>      T t;
> 
>      ... I can call t.toString() ...
> 
>      ... But I can't call t.intValue() because I have no reason to 
> believe this method exists on T ...
> }
> 


From paul.sandoz at oracle.com  Tue Aug  4 15:15:36 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 17:15:36 +0200
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
Message-ID: <767E6963-7D7E-41BA-B1CE-6F1A169F2D4F@oracle.com>

Hi Michael,

Thanks for the detailed response.

Not sure how we can solve this particular use-case, contended arrays, without either HotSpot getting smarter on such bounds checks or supporting alternative array layouts.

You could try out #3 by setting the experimental flag:

  -XX:+UnlockExperimentalVMOptions -XX:+TrustFinalNonStaticFields

But i don?t know if HotSpot will correctly associate indexMask with the array length.

Paul.

On 3 Aug 2015, at 03:53, Michael Barker <mikeb01 at gmail.com> wrote:

> Hi,
> 
> Having played with it a bit more, I can get the bound check removed under one specific arrangement of the code, the following is for the RingBufferFields.elementAt:
> 
> 1)  return (E) entries[((int) sequence) & (entries.length - 1)];
> 
> This works and I get the pattern mentioned Paul's example.  There is a drawback to implementing it this way, details below.
> 
> 2)  return (E) entries[(int) sequence & (entries.length - 1)];
> 
> Note the position of the brackets.  In this case entries.length is being promoted to a long before applying the mask, then being cast down to an int, which seems to trip up the compiler.
> 
> 3)  return (E) entries[((int) sequence) & indexMask];  // indexMask is a final field of value entries.length - 1
> 
> I suspect this is because the compiler can't assume that final fields are actually final.
> 
> 4)  return (E) entries[BUFFER_PAD + (((int) sequence) & (entries.length - ((BUFFER_PAD * 2) + 1)))];
> 
> I'm guessing it gets just too complex for the compiler to figure our that the resulting value will be less that entries.length.
> 
> One of the niggles with approach #1, is that I need to reference entries.length at the call site and can't use a separate field to store the value.  This can cause issue in a concurrent ring-buffer-like structures as the array length can end up sharing a cache line with the array itself.  So if a producer thread writes into one of the first 15 array slots (worst case), the whole line including the part containing the length field will be invalid on the consumer's core resulting in an additional cache miss in certain cases.  This is probably less of an issue for the default set up of the disruptor as we don't actually replace the references inside of the entries array, but a number of fast queue implementations would suffer.  The developer is caught having to make a trade-off between reducing false sharing and removing bounds checking.
> 
> Mike.
> 
> 
> On 1 August 2015 at 00:18, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> On 31 Jul 2015, at 07:43, Michael Barker <mikeb01 at gmail.com> wrote:
> 
> > Hi Paul,
> >
> > I've had a look at the patch that you mentioned and AFAICT it doesn't seem to be able to eliminate the bounds check, even if I remove the array padding.  Just to confirm my analysis the assembler around the aaload instruction looks like:
> >
> > 0x00007f627d6b3aea: cmp    %ebx,%edx
> > 0x00007f627d6b3aec: jae    0x00007f627d6b3e0c
> > 0x00007f627d6b3af2: mov    %r8,%r13
> > 0x00007f627d6b3af5: mov    %r11d,%r8d
> > 0x00007f627d6b3af8: mov    0x10(%rax,%rdx,4),%r11d  ;*aaload
> >
> > I'm guessing that the cmp/jae pair is the bounds check?
> >
> 
> Yes, i am assuming that is generated code of RingBuffer.elementAt (aaload) and not MultiProducerSequencer. I suspect the padding is throwing the compiler off the scent (it does not know that indexMask is less than entries.length - BUFFER_INDEX).
> 
> For an array access such as:
> 
>   int j = i & (a.length - 1);
>   X x = a[j];
> 
> I would expect to observe something like:
> 
>   test   %edi,%edi
>   jbe    ?
> 
> The bound check should get strength reduced to checking if the array length is zero, and i would expect such a test to be hoisted out of any loop (and get folded into another dominating array length check, if any).
> 
> Here is an example, given this benchmark method:
> 
> @Benchmark
> public int relaxed_r_aa() {
>     Value[] _receiver = receiver;
>     int sum = 0;
>     for (int i = start; i < end; i++) {
>         int j = i & (_receiver.length - 1);
>         sum += _receiver[j].i;
>     }
>     return sum;
> }
> 
> Without the patch the following code is generated (when loop unrolling is switched off):
> 
> : mov    0xc(%r12,%rbx,8),%r9d  ;*arraylength
> : mov    %r9d,%r11d
> : dec    %r11d
> : lea    (%r12,%rbx,8),%rcx
> : xor    %eax,%eax          ;*iload_3
> 
> <loop>: mov    %r11d,%ebp
> : and    %r10d,%ebp         ;*iand
> : cmp    %r9d,%ebp
> : jae    <bounds-fail>
> : mov    0x10(%rcx,%rbp,4),%edi  ;*aaload
> : add    0xc(%r12,%rdi,8),%eax  ;*iadd
> : inc    %r10d              ;*iinc
> : cmp    %r8d,%r10d
> : jl     <loop>  ;*if_icmpge
> 
> 
> When the patch is applied the following code is generated:
> 
> : mov    0xc(%r12,%rbp,8),%r9d  ;*arraylength
> : test   %r9d,%r9d
> : jbe    <bounds-fail>
> : dec    %r9d
> : lea    (%r12,%rbp,8),%r8
> : data32 nopw 0x0(%rax,%rax,1)
> : data32 data32 xchg %ax,%ax  ;*iload_3
> 
> <loop>: mov    %r9d,%ebx
> : and    %r11d,%ebx
> : mov    0x10(%r8,%rbx,4),%ebx  ;*aaload
> : add    0xc(%r12,%rbx,8),%eax  ;*iadd
> : inc    %r11d              ;*iinc
> : cmp    %r10d,%r11d
> : jl     <loop>  ;*if_icmpge
> 
> 
> 
> > A quick note on the patch, it merged, but didn't compile.  There seemed to be a signature change on the signature of ConINode::make, so I changed line 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);' to 'return ConINode::make(1);'.  That let it compile, but I don't really understand the code so I'm not sure if it is semantically correct.
> >
> 
> Oops sorry about that, i uploaded a new revision of the patch the same fix that you applied.
> 
> Paul.
> 
> 


From vitalyd at gmail.com  Tue Aug  4 15:29:18 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 4 Aug 2015 11:29:18 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <767E6963-7D7E-41BA-B1CE-6F1A169F2D4F@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<767E6963-7D7E-41BA-B1CE-6F1A169F2D4F@oracle.com>
Message-ID: <CAHjP37HBa=tS3UZLemBJFS=57giY+KndYFj8E5YEG_an2S6a_A@mail.gmail.com>

TrustFinalNonStaticFields only works if the holder class is static final.
You can see my thread on hotspot-compiler about this flag from a few months
ago:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017739.html

On Tue, Aug 4, 2015 at 11:15 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Michael,
>
> Thanks for the detailed response.
>
> Not sure how we can solve this particular use-case, contended arrays,
> without either HotSpot getting smarter on such bounds checks or supporting
> alternative array layouts.
>
> You could try out #3 by setting the experimental flag:
>
>   -XX:+UnlockExperimentalVMOptions -XX:+TrustFinalNonStaticFields
>
> But i don?t know if HotSpot will correctly associate indexMask with the
> array length.
>
> Paul.
>
> On 3 Aug 2015, at 03:53, Michael Barker <mikeb01 at gmail.com> wrote:
>
> > Hi,
> >
> > Having played with it a bit more, I can get the bound check removed
> under one specific arrangement of the code, the following is for the
> RingBufferFields.elementAt:
> >
> > 1)  return (E) entries[((int) sequence) & (entries.length - 1)];
> >
> > This works and I get the pattern mentioned Paul's example.  There is a
> drawback to implementing it this way, details below.
> >
> > 2)  return (E) entries[(int) sequence & (entries.length - 1)];
> >
> > Note the position of the brackets.  In this case entries.length is being
> promoted to a long before applying the mask, then being cast down to an
> int, which seems to trip up the compiler.
> >
> > 3)  return (E) entries[((int) sequence) & indexMask];  // indexMask is a
> final field of value entries.length - 1
> >
> > I suspect this is because the compiler can't assume that final fields
> are actually final.
> >
> > 4)  return (E) entries[BUFFER_PAD + (((int) sequence) & (entries.length
> - ((BUFFER_PAD * 2) + 1)))];
> >
> > I'm guessing it gets just too complex for the compiler to figure our
> that the resulting value will be less that entries.length.
> >
> > One of the niggles with approach #1, is that I need to reference
> entries.length at the call site and can't use a separate field to store the
> value.  This can cause issue in a concurrent ring-buffer-like structures as
> the array length can end up sharing a cache line with the array itself.  So
> if a producer thread writes into one of the first 15 array slots (worst
> case), the whole line including the part containing the length field will
> be invalid on the consumer's core resulting in an additional cache miss in
> certain cases.  This is probably less of an issue for the default set up of
> the disruptor as we don't actually replace the references inside of the
> entries array, but a number of fast queue implementations would suffer.
> The developer is caught having to make a trade-off between reducing false
> sharing and removing bounds checking.
> >
> > Mike.
> >
> >
> > On 1 August 2015 at 00:18, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> >
> > On 31 Jul 2015, at 07:43, Michael Barker <mikeb01 at gmail.com> wrote:
> >
> > > Hi Paul,
> > >
> > > I've had a look at the patch that you mentioned and AFAICT it doesn't
> seem to be able to eliminate the bounds check, even if I remove the array
> padding.  Just to confirm my analysis the assembler around the aaload
> instruction looks like:
> > >
> > > 0x00007f627d6b3aea: cmp    %ebx,%edx
> > > 0x00007f627d6b3aec: jae    0x00007f627d6b3e0c
> > > 0x00007f627d6b3af2: mov    %r8,%r13
> > > 0x00007f627d6b3af5: mov    %r11d,%r8d
> > > 0x00007f627d6b3af8: mov    0x10(%rax,%rdx,4),%r11d  ;*aaload
> > >
> > > I'm guessing that the cmp/jae pair is the bounds check?
> > >
> >
> > Yes, i am assuming that is generated code of RingBuffer.elementAt
> (aaload) and not MultiProducerSequencer. I suspect the padding is throwing
> the compiler off the scent (it does not know that indexMask is less than
> entries.length - BUFFER_INDEX).
> >
> > For an array access such as:
> >
> >   int j = i & (a.length - 1);
> >   X x = a[j];
> >
> > I would expect to observe something like:
> >
> >   test   %edi,%edi
> >   jbe    ?
> >
> > The bound check should get strength reduced to checking if the array
> length is zero, and i would expect such a test to be hoisted out of any
> loop (and get folded into another dominating array length check, if any).
> >
> > Here is an example, given this benchmark method:
> >
> > @Benchmark
> > public int relaxed_r_aa() {
> >     Value[] _receiver = receiver;
> >     int sum = 0;
> >     for (int i = start; i < end; i++) {
> >         int j = i & (_receiver.length - 1);
> >         sum += _receiver[j].i;
> >     }
> >     return sum;
> > }
> >
> > Without the patch the following code is generated (when loop unrolling
> is switched off):
> >
> > : mov    0xc(%r12,%rbx,8),%r9d  ;*arraylength
> > : mov    %r9d,%r11d
> > : dec    %r11d
> > : lea    (%r12,%rbx,8),%rcx
> > : xor    %eax,%eax          ;*iload_3
> >
> > <loop>: mov    %r11d,%ebp
> > : and    %r10d,%ebp         ;*iand
> > : cmp    %r9d,%ebp
> > : jae    <bounds-fail>
> > : mov    0x10(%rcx,%rbp,4),%edi  ;*aaload
> > : add    0xc(%r12,%rdi,8),%eax  ;*iadd
> > : inc    %r10d              ;*iinc
> > : cmp    %r8d,%r10d
> > : jl     <loop>  ;*if_icmpge
> >
> >
> > When the patch is applied the following code is generated:
> >
> > : mov    0xc(%r12,%rbp,8),%r9d  ;*arraylength
> > : test   %r9d,%r9d
> > : jbe    <bounds-fail>
> > : dec    %r9d
> > : lea    (%r12,%rbp,8),%r8
> > : data32 nopw 0x0(%rax,%rax,1)
> > : data32 data32 xchg %ax,%ax  ;*iload_3
> >
> > <loop>: mov    %r9d,%ebx
> > : and    %r11d,%ebx
> > : mov    0x10(%r8,%rbx,4),%ebx  ;*aaload
> > : add    0xc(%r12,%rbx,8),%eax  ;*iadd
> > : inc    %r11d              ;*iinc
> > : cmp    %r10d,%r11d
> > : jl     <loop>  ;*if_icmpge
> >
> >
> >
> > > A quick note on the patch, it merged, but didn't compile.  There
> seemed to be a signature change on the signature of ConINode::make, so I
> changed line 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);'
> to 'return ConINode::make(1);'.  That let it compile, but I don't really
> understand the code so I'm not sure if it is semantically correct.
> > >
> >
> > Oops sorry about that, i uploaded a new revision of the patch the same
> fix that you applied.
> >
> > Paul.
> >
> >
>
>

From paul.sandoz at oracle.com  Tue Aug  4 15:35:21 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 17:35:21 +0200
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CAHjP37HBa=tS3UZLemBJFS=57giY+KndYFj8E5YEG_an2S6a_A@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<767E6963-7D7E-41BA-B1CE-6F1A169F2D4F@oracle.com>
	<CAHjP37HBa=tS3UZLemBJFS=57giY+KndYFj8E5YEG_an2S6a_A@mail.gmail.com>
Message-ID: <6B3FFF0E-5A99-4A89-A6D1-3EBE11FE79A4@oracle.com>


On 4 Aug 2015, at 17:29, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> TrustFinalNonStaticFields only works if the holder class is static final.  You can see my thread on hotspot-compiler about this flag from a few months ago: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017739.html
> 

Ah! thanks for the clarification, i forgot about that constraint.

Paul.

From brian.goetz at oracle.com  Tue Aug  4 16:07:33 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 4 Aug 2015 12:07:33 -0400
Subject: "Model 2" prototype status
In-Reply-To: <1438699645.4725.33.camel@sludev.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
Message-ID: <55C0E345.4050503@oracle.com>

Much of this has been covered already in the "Why not 'just' add an Any 
type?" discussion (see the archives), so I'll try to avoid repeating 
those points.  The short answer is "yes, we've thought about this quite 
a bit, and we feel the result would only be superficially satisfying." 
(And I regret to say, I won't be able to continue this discussion 
further; extended discussions on "why not take a completely different 
direction" -- especially when that direction is one we've already 
considered -- are just too much of a distraction, so please, hold your 
responses.)

> Simple question... I can't help to think ( although I may be incorrect )
> that a massive amount of this issue goes away ( for new programs ) with
> a unified object/valueType hierarchy and availability of autoboxing
> tweaks.

It depends on your goal, of course.  If the goal is simply to let you 
type List<int> instead of List<Integer> (saving four keystrokes), then 
it would be trivial to simply interpret List<int> as the boxed 
List<Integer>.  But that doesn't meet our goals, which is enabling 
generics to play nicely with values without giving up the key 
performance benefits of values -- density (no header or other memory 
overhead) and flatness (no indirection or pointers.)  Any solution that 
relies on autoboxing fails to meet these goals.

As a simple summary of goal, if ArrayList<int> is not backed by a real 
int[], then we've failed.

When you say "a massive amount of this issue goes away", what I think 
you actually mean is it "recedes from where I can see it."  But that 
doesn't make it go away.  (There can be in pushing the complexity where 
the user doesn't have to see it, if the problem is just being kicked 
down the road, you're not necessarily doing anyone a favor.)

Autoboxing simply kicks the problem down the road.  I think its fair to 
say that, if the performance of boxing didn't suck so badly, we wouldn't 
be bothering with this in the first place -- people would be happy 
enough to just write ArrayList<Integer>.  (The next obvious question is 
"Well, why not just fix that?"  And the answer should be equally obvious 
-- if we had an easy fix for this, we would have done it years ago.)

Your "for new programs" observation is too important to be limited to a 
parenthetical.  If we were building a new language from scratch, we 
would surely make different decisions.  And its worth spending some time 
asking ourselves what the ideal might be in that situation, but we can't 
let ourselves be too drawn into the fantasy that we have a clean sheet 
of paper to work with.  Migration compatibility (not just for 
implementations of generic classes, but also for their clients and 
subclasses) is absolutely critical -- and it's going to cause warts. 
(Its OK to regret said warts, or wonder whether a different set of warts 
would be more palatable -- but not really reasonable to conclude that 
"warts -> someone made a mistake".)

 > 2. Value type hierarchy base object appearing to the compiler has
 > Object.
 >
 > Some popular languages seem to have success with this approach.  And at
 > least on the surface it seems to solve nullability and and host of other
 > API issues that have been discussed.

Other languages and platforms have attempted to unify objects and 
primitives -- with varying degrees of failure and success.  Paul 
Philips' talks circa 2013 -- at JVMLS and Scala PNW -- highlight the 
challenges of trying to unify references and primitives on the JVM while 
retaining any sort of compatibility.  The poor performance of Scala 
streams over "primitives" (see Aggelos Biboudis' paper on this) proceeds 
mostly from this attempt to unify; the result is that they can't prevent 
the boxing, and performance suffers.  .NET took the path of unifying 
structs and objects (but regrettably, allowed their structs to be 
mutable.)  This has been partially successful but also less than 
perfect; we've tried to learn what we can from their experience.

Our thinking continues to be: primitives/values and references are 
different, and papering over the differences with superficial remedies 
ultimately causes more trouble than its worth.

> More out of curiosity than anything else, is there anything inherently
> wrong/broken with the above approach?

There's nothing inherently wrong with the concept; it has pros/cons like 
anything else.  What is inherently wrong is the assumption that it is 
somehow any simpler or less work.

HTH,
-Brian


From martijnverburg at gmail.com  Tue Aug  4 16:44:38 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 4 Aug 2015 17:44:38 +0100
Subject: "Model 2" prototype status
In-Reply-To: <55C0E345.4050503@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
Message-ID: <CAP7YuATDerZxAtWph3qNYDB7_8XZ5JTBpPGsJ4mhexOBuyFyMQ@mail.gmail.com>

Hi all,

As an aside - to get some of the in depth background behind this proposal
(and alternatives) then I highly recommend going to the JVM (language)
summit (http://openjdk.java.net/projects/mlvm/jvmlangsummit/). It's almost
impossible to write up all of thought processes etc (would take volumes and
1000's of hours) on this list as much as Brian et al would like to, much
easier to get the info in person with the higher bandwidth so to speak.

Cheers,
Martijn

On 4 August 2015 at 17:07, Brian Goetz <brian.goetz at oracle.com> wrote:

> Much of this has been covered already in the "Why not 'just' add an Any
> type?" discussion (see the archives), so I'll try to avoid repeating those
> points.  The short answer is "yes, we've thought about this quite a bit,
> and we feel the result would only be superficially satisfying." (And I
> regret to say, I won't be able to continue this discussion further;
> extended discussions on "why not take a completely different direction" --
> especially when that direction is one we've already considered -- are just
> too much of a distraction, so please, hold your responses.)
>
> Simple question... I can't help to think ( although I may be incorrect )
>> that a massive amount of this issue goes away ( for new programs ) with
>> a unified object/valueType hierarchy and availability of autoboxing
>> tweaks.
>>
>
> It depends on your goal, of course.  If the goal is simply to let you type
> List<int> instead of List<Integer> (saving four keystrokes), then it would
> be trivial to simply interpret List<int> as the boxed List<Integer>.  But
> that doesn't meet our goals, which is enabling generics to play nicely with
> values without giving up the key performance benefits of values -- density
> (no header or other memory overhead) and flatness (no indirection or
> pointers.)  Any solution that relies on autoboxing fails to meet these
> goals.
>
> As a simple summary of goal, if ArrayList<int> is not backed by a real
> int[], then we've failed.
>
> When you say "a massive amount of this issue goes away", what I think you
> actually mean is it "recedes from where I can see it."  But that doesn't
> make it go away.  (There can be in pushing the complexity where the user
> doesn't have to see it, if the problem is just being kicked down the road,
> you're not necessarily doing anyone a favor.)
>
> Autoboxing simply kicks the problem down the road.  I think its fair to
> say that, if the performance of boxing didn't suck so badly, we wouldn't be
> bothering with this in the first place -- people would be happy enough to
> just write ArrayList<Integer>.  (The next obvious question is "Well, why
> not just fix that?"  And the answer should be equally obvious -- if we had
> an easy fix for this, we would have done it years ago.)
>
> Your "for new programs" observation is too important to be limited to a
> parenthetical.  If we were building a new language from scratch, we would
> surely make different decisions.  And its worth spending some time asking
> ourselves what the ideal might be in that situation, but we can't let
> ourselves be too drawn into the fantasy that we have a clean sheet of paper
> to work with.  Migration compatibility (not just for implementations of
> generic classes, but also for their clients and subclasses) is absolutely
> critical -- and it's going to cause warts. (Its OK to regret said warts, or
> wonder whether a different set of warts would be more palatable -- but not
> really reasonable to conclude that "warts -> someone made a mistake".)
>
> > 2. Value type hierarchy base object appearing to the compiler has
> > Object.
> >
> > Some popular languages seem to have success with this approach.  And at
> > least on the surface it seems to solve nullability and and host of other
> > API issues that have been discussed.
>
> Other languages and platforms have attempted to unify objects and
> primitives -- with varying degrees of failure and success.  Paul Philips'
> talks circa 2013 -- at JVMLS and Scala PNW -- highlight the challenges of
> trying to unify references and primitives on the JVM while retaining any
> sort of compatibility.  The poor performance of Scala streams over
> "primitives" (see Aggelos Biboudis' paper on this) proceeds mostly from
> this attempt to unify; the result is that they can't prevent the boxing,
> and performance suffers.  .NET took the path of unifying structs and
> objects (but regrettably, allowed their structs to be mutable.)  This has
> been partially successful but also less than perfect; we've tried to learn
> what we can from their experience.
>
> Our thinking continues to be: primitives/values and references are
> different, and papering over the differences with superficial remedies
> ultimately causes more trouble than its worth.
>
> More out of curiosity than anything else, is there anything inherently
>> wrong/broken with the above approach?
>>
>
> There's nothing inherently wrong with the concept; it has pros/cons like
> anything else.  What is inherently wrong is the assumption that it is
> somehow any simpler or less work.
>
> HTH,
> -Brian
>
>

From simon at ochsenreither.de  Tue Aug  4 19:09:42 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Tue, 4 Aug 2015 21:09:42 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <55C0E345.4050503@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
Message-ID: <1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>


> Other languages and platforms have attempted to unify objects and
> primitives -- with varying degrees of failure and success. Paul
> Philips' talks circa 2013 -- at JVMLS and Scala PNW -- highlight the
> challenges of trying to unify references and primitives on the JVM while
> retaining any sort of compatibility. The poor performance of Scala
> streams over "primitives" (see Aggelos Biboudis' paper on this) proceeds
> mostly from this attempt to unify; the result is that they can't prevent
> the boxing, and performance suffers. .NET took the path of unifying
> structs and objects (but regrettably, allowed their structs to be
> mutable.) This has been partially successful but also less than
> perfect; we've tried to learn what we can from their experience.
 
I have seen this claim quite a few times already, and I think it's not a fitting
characterization of the issue.
 
I'll try to clarify a bit:
 
* The whole issue with unification and the Any/AnyRef/AnyVal hierarchy is that
we (in Scala) have to fight the JVM for every tiny bit of additional
correctness.
Sometimes, it's just a case of diminishing returns given the constraint that we
want to have a execution model where vanilla class files are executed on the
JVM, and not some "ScalaVM inside the JVM" approach.
If the JVM provides better support for these things, most of the issues we see
in Scala will just go away for good.
* The performance of Scala collection operations in the paper you mentioned is
unrelated to that.
Constructing a data structure after each operation is expensive (and a bad idea
from my POV), boxing is probably the least pressing issue. The paper [10]
referenced by Biboudis doesn't support his claim in my opinion, either. Of
course, getting rid of boxing is great, but no amount of boxing elimination can
turn an O(n) collection design into an O(1) collection design. (Which is pretty
much what ScalaBlitz does, last time it looked: It tries to eliminate the
construction of intermediate data structures, of course things get boxed less if
less work is done, but that's kind of obvious.)
I think the .NET devs have done a pretty good job overall. Apart from allowing
mutability, not supporting Void/Unit and completely messing up the semantics of
static inside of generic classes, things work quite well. They are sidestepping
the whole variance issue, but I wouldn't claim that that's not a valid solution
for them.

From john.r.rose at oracle.com  Tue Aug  4 19:20:28 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 4 Aug 2015 12:20:28 -0700
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CAHjP37GxarErRk-WMAjgCVW=Wqy182S0iscTwzmVrRH8qi1hLw@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<55B3D6D0.5090709@oracle.com>
	<CALwNKeQXPB14OMnZu0uOP1mqWSZiRrJYsb3dagazQR1VCKxBKA@mail.gmail.com>
	<55B640E0.50409@oracle.com>
	<CALwNKeSRrOwSDkU88PkrXopn7WQ=e9fXFk=rJ80hOj5S+CEExQ@mail.gmail.com>
	<314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com>
	<CAHjP37H42maktvi1L2QqJHjaCZC2dpES_FEHcT2vdR+SnCJdUA@mail.gmail.com>
	<BD08CEC7-CA67-4EBF-AB06-AC6DAED6C943@gmail.com>
	<55B7A128.8070005@redhat.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com>
	<CALwNKeQ48vS3MV6-_45fzw8nohjyN1r7uLae8w45Ks=-_piajw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3C36@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37GxarErRk-WMAjgCVW=Wqy182S0iscTwzmVrRH8qi1hLw@mail.gmail.com>
Message-ID: <44BA6554-4FE6-4EE2-AF1C-4052A9CB199B@oracle.com>

On Jul 28, 2015, at 3:01 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Is that in scope though given that VarHandles are really meant to replace
> Unsafe usage, and I don't see how Unsafe supports that "naked"/default
> aspect today.

To be fair, Unsafe doesn't support any form of access that is user-friendly.

VHs add lots of usability stuff that goes beyond Unsafe, but along a new vector.

A "natural" access mode (respecting underlying variable declaration) is useful
not because it cannot be expressed differently, but because it is safer to use.
Safer because less surprising and easier to reason about.

? John

From john.r.rose at oracle.com  Tue Aug  4 19:31:09 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 4 Aug 2015 12:31:09 -0700
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
Message-ID: <E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>


On Aug 2, 2015, at 6:53 PM, Michael Barker <mikeb01 at gmail.com> wrote:
> 
> 3)  return (E) entries[((int) sequence) & indexMask];  // indexMask is a
> final field of value entries.length - 1
> 
> I suspect this is because the compiler can't assume that final fields are
> actually final.

Yes.  The JIT does not track the identity indexMask==entries.length.
And it needs to work directly with entries.length if it is to prove a safe
array access.

> 4)  return (E) entries[BUFFER_PAD + (((int) sequence) & (entries.length -
> ((BUFFER_PAD * 2) + 1)))];
> 
> I'm guessing it gets just too complex for the compiler to figure our that
> the resulting value will be less that entries.length.

True.  In particular, the JIT (as of today) cannot prove that the subexpression
(entries.length - FOO) is positive.  If it goes negative, then the "&" hack fails
to do what we want.

You could try this one:

5)  return (E) entries[mapSequenceToIndex(sequence, entries.length >> 1) & entries.length];

where the following method may or may not be hand-inlined:

   static int mapSequenceToIndex(long sequence, int logicalLength) {
      return sequence & (logicalLength-1) + BUFFER_PAD;
   }

Season to taste?  The point is that the JIT sees any random int expression,
followed by "& entries.length", which is enough to elide the range check.

? John

From vitalyd at gmail.com  Tue Aug  4 19:51:36 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 4 Aug 2015 15:51:36 -0400
Subject: "Model 2" prototype status
In-Reply-To: <1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>

I don't know why mutability of structs in .NET keeps being referred to as a
mistake.  Sure it can lead to bugs, but so can many other things if not
used properly.  It's a useful tool to have in some occasions (given .net
supports passing them by ref).

sent from my phone
On Aug 4, 2015 3:10 PM, "Simon Ochsenreither" <simon at ochsenreither.de>
wrote:

>
> > Other languages and platforms have attempted to unify objects and
> > primitives -- with varying degrees of failure and success. Paul
> > Philips' talks circa 2013 -- at JVMLS and Scala PNW -- highlight the
> > challenges of trying to unify references and primitives on the JVM while
> > retaining any sort of compatibility. The poor performance of Scala
> > streams over "primitives" (see Aggelos Biboudis' paper on this) proceeds
> > mostly from this attempt to unify; the result is that they can't prevent
> > the boxing, and performance suffers. .NET took the path of unifying
> > structs and objects (but regrettably, allowed their structs to be
> > mutable.) This has been partially successful but also less than
> > perfect; we've tried to learn what we can from their experience.
>
> I have seen this claim quite a few times already, and I think it's not a
> fitting
> characterization of the issue.
>
> I'll try to clarify a bit:
>
> * The whole issue with unification and the Any/AnyRef/AnyVal hierarchy is
> that
> we (in Scala) have to fight the JVM for every tiny bit of additional
> correctness.
> Sometimes, it's just a case of diminishing returns given the constraint
> that we
> want to have a execution model where vanilla class files are executed on
> the
> JVM, and not some "ScalaVM inside the JVM" approach.
> If the JVM provides better support for these things, most of the issues we
> see
> in Scala will just go away for good.
> * The performance of Scala collection operations in the paper you
> mentioned is
> unrelated to that.
> Constructing a data structure after each operation is expensive (and a bad
> idea
> from my POV), boxing is probably the least pressing issue. The paper [10]
> referenced by Biboudis doesn't support his claim in my opinion, either. Of
> course, getting rid of boxing is great, but no amount of boxing
> elimination can
> turn an O(n) collection design into an O(1) collection design. (Which is
> pretty
> much what ScalaBlitz does, last time it looked: It tries to eliminate the
> construction of intermediate data structures, of course things get boxed
> less if
> less work is done, but that's kind of obvious.)
> I think the .NET devs have done a pretty good job overall. Apart from
> allowing
> mutability, not supporting Void/Unit and completely messing up the
> semantics of
> static inside of generic classes, things work quite well. They are
> sidestepping
> the whole variance issue, but I wouldn't claim that that's not a valid
> solution
> for them.
>

From vitalyd at gmail.com  Tue Aug  4 19:54:15 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 4 Aug 2015 15:54:15 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <44BA6554-4FE6-4EE2-AF1C-4052A9CB199B@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<55B3D6D0.5090709@oracle.com>
	<CALwNKeQXPB14OMnZu0uOP1mqWSZiRrJYsb3dagazQR1VCKxBKA@mail.gmail.com>
	<55B640E0.50409@oracle.com>
	<CALwNKeSRrOwSDkU88PkrXopn7WQ=e9fXFk=rJ80hOj5S+CEExQ@mail.gmail.com>
	<314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com>
	<CAHjP37H42maktvi1L2QqJHjaCZC2dpES_FEHcT2vdR+SnCJdUA@mail.gmail.com>
	<BD08CEC7-CA67-4EBF-AB06-AC6DAED6C943@gmail.com>
	<55B7A128.8070005@redhat.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com>
	<CALwNKeQ48vS3MV6-_45fzw8nohjyN1r7uLae8w45Ks=-_piajw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3C36@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37GxarErRk-WMAjgCVW=Wqy182S0iscTwzmVrRH8qi1hLw@mail.gmail.com>
	<44BA6554-4FE6-4EE2-AF1C-4052A9CB199B@oracle.com>
Message-ID: <CAHjP37EVtC34FzPN_MKhsUo0Z4zxgB2LP1OHBnmC6yR=yaJWpQ@mail.gmail.com>

>
> A "natural" access mode (respecting underlying variable declaration) is
> useful
> not because it cannot be expressed differently, but because it is safer to
> use.
> Safer because less surprising and easier to reason about.


I don't see how it's safer to use as it hampers readability.  With ordering
semantics, it's very important to see this at the callsite and not some
distance away.

On Tue, Aug 4, 2015 at 3:20 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Jul 28, 2015, at 3:01 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> Is that in scope though given that VarHandles are really meant to replace
> Unsafe usage, and I don't see how Unsafe supports that "naked"/default
> aspect today.
>
>
> To be fair, Unsafe doesn't support any form of access that is
> user-friendly.
>
> VHs add lots of usability stuff that goes beyond Unsafe, but along a new
> vector.
>
> A "natural" access mode (respecting underlying variable declaration) is
> useful
> not because it cannot be expressed differently, but because it is safer to
> use.
> Safer because less surprising and easier to reason about.
>
> ? John
>

From eliasvasylenko at gmail.com  Tue Aug  4 20:24:52 2015
From: eliasvasylenko at gmail.com (elias vasylenko)
Date: Tue, 04 Aug 2015 20:24:52 +0000
Subject: "Model 2" prototype status
In-Reply-To: <55BD3E97.3020206@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
Message-ID: <CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>

This all sounds pretty encouraging so far to me. I feel like all my major
tick boxes are being steadily, if tentatively, filled. Thanks for the
update!

I do have one new concern though - something you said earlier jumped out at
me, Brian:

"So its quite possible that Foo<any T extends Comparable> may in fact be
meaningful.  (And if that's the case, primitives might join the party
too.)  Or not, we're not sure yet."

I suppose this must mean there is a realistic possibility that will *not*
in fact be meaningful, which is a surprise to me... Is this something that
has been discussed in more depth and I missed it? If anyone could expand on
this a little (preferably to give a little reassurance that I'm
overreacting to the importance, or that the chances are low for this to end
up being the case!) I'd be pretty relieved. It feels like it'd be a pretty
huge blow, and given my (limited) understanding I can't see what
particularly troublesome issues this even presents.

Cheers,

Eli

On Sat, 1 Aug 2015 at 22:49 Brian Goetz <brian.goetz at oracle.com> wrote:

> > I dislike the Foo<ref> / Foo<any> thing for several reasons.
>
> Not surprising.  This wasn't our first choice either.
>
> We spent a great deal of effort investigating whether it was possible to
> re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
> tvar, and to mean Foo<any> when the corresponding tvar is an any tvar.
> Seems obvious, right?
>
> Several hundred hours later, the short answer is that things fall apart
> when a library is any-fied and the client is not recompiled; this would
> make any-fication a binary-incompatible change, which would be a loser.
>   So with tears in our eyes, we reluctantly concluded that we needed to
> differentiate between Foo<ref> and Foo<any>.  Once we swallowed that
> pill, many things snapped into place.  So as sad as it is to have two
> kinds of wildcard, I'm pretty sure its the right call.
>
> You prefer another syntax?  Sure, I'm sure there are alternatives.  We
> can talk about it -- but not this year!  We have way more important
> things to work out before that comes anywhere near the top of the list.
>
> As to bounds...  we're still working out the details of the interaction
> between value types and interfaces.  So its quite possible that Foo<any
> T extends Comparable> may in fact be meaningful.  (And if that's the
> case, primitives might join the party too.)  Or not, we're not sure yet.
>
>
>

From martijnverburg at gmail.com  Tue Aug  4 20:33:42 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 4 Aug 2015 21:33:42 +0100
Subject: "Model 2" prototype status
In-Reply-To: <CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
Message-ID: <CAP7YuASd2-NPHrS5pviT35XN+OvnQg4X4kog_teH_DVJVx_SWA@mail.gmail.com>

Hi Eli,

It's simply too early to tell and will need some more investigation by the
core valhalla team, we're going to have to be patient and wait until
they've explored this particular interaction further :-).

Cheers,
Martijn

On 4 August 2015 at 21:24, elias vasylenko <eliasvasylenko at gmail.com> wrote:

> This all sounds pretty encouraging so far to me. I feel like all my major
> tick boxes are being steadily, if tentatively, filled. Thanks for the
> update!
>
> I do have one new concern though - something you said earlier jumped out at
> me, Brian:
>
> "So its quite possible that Foo<any T extends Comparable> may in fact be
> meaningful.  (And if that's the case, primitives might join the party
> too.)  Or not, we're not sure yet."
>
> I suppose this must mean there is a realistic possibility that will *not*
> in fact be meaningful, which is a surprise to me... Is this something that
> has been discussed in more depth and I missed it? If anyone could expand on
> this a little (preferably to give a little reassurance that I'm
> overreacting to the importance, or that the chances are low for this to end
> up being the case!) I'd be pretty relieved. It feels like it'd be a pretty
> huge blow, and given my (limited) understanding I can't see what
> particularly troublesome issues this even presents.
>
> Cheers,
>
> Eli
>
> On Sat, 1 Aug 2015 at 22:49 Brian Goetz <brian.goetz at oracle.com> wrote:
>
> > > I dislike the Foo<ref> / Foo<any> thing for several reasons.
> >
> > Not surprising.  This wasn't our first choice either.
> >
> > We spent a great deal of effort investigating whether it was possible to
> > re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
> > tvar, and to mean Foo<any> when the corresponding tvar is an any tvar.
> > Seems obvious, right?
> >
> > Several hundred hours later, the short answer is that things fall apart
> > when a library is any-fied and the client is not recompiled; this would
> > make any-fication a binary-incompatible change, which would be a loser.
> >   So with tears in our eyes, we reluctantly concluded that we needed to
> > differentiate between Foo<ref> and Foo<any>.  Once we swallowed that
> > pill, many things snapped into place.  So as sad as it is to have two
> > kinds of wildcard, I'm pretty sure its the right call.
> >
> > You prefer another syntax?  Sure, I'm sure there are alternatives.  We
> > can talk about it -- but not this year!  We have way more important
> > things to work out before that comes anywhere near the top of the list.
> >
> > As to bounds...  we're still working out the details of the interaction
> > between value types and interfaces.  So its quite possible that Foo<any
> > T extends Comparable> may in fact be meaningful.  (And if that's the
> > case, primitives might join the party too.)  Or not, we're not sure yet.
> >
> >
> >
>

From brian.goetz at oracle.com  Tue Aug  4 20:42:51 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 4 Aug 2015 16:42:51 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
Message-ID: <55C123CB.3030902@oracle.com>

> This all sounds pretty encouraging so far to me. I feel like all my major tick boxes are being steadily, if tentatively, filled. Thanks for the update!

Thanks!  Some boxes ticked, many more boxes to go...

> I suppose this must mean there is a realistic possibility that will
> /not/ in fact be meaningful, which is a surprise to me... Is this
> something that has been discussed in more depth and I missed it? If
> anyone could expand on this a little (preferably to give a little
> reassurance that I'm overreacting to the importance, or that the chances
> are low for this to end up being the case!) I'd be pretty relieved. It
> feels like it'd be a pretty huge blow, and given my (limited)
> understanding I can't see what particularly troublesome issues this even
> presents.

Martijn is exactly right; we have to be very conservative about what we 
commit to, and want to wait to work through the issues.  Almost nothing 
is trivial; it is a frequent occurrence that something starts out 
looking like "couldn't possibly be troublesome" and then surprising 
trouble ensues.  Often, we end up with conflicts between multiple softer 
goals, so by framing them as soft goals rather than assuming they are a 
done deal, we are more likely to avoid "boxing" ourselves into a corner.

We're on board with the idea that having values implement interfaces 
seems desirable.  So don't worry about that.

But, what does the implementation look like, and how do we balance the 
various goals?  As one example of the kind of thing we've yet to fully 
evaluate...

One goal is that values should be dense and flat, meaning no extraneous 
storage overhead (like headers).  If a value has no header, as we'd like 
it, what happens here:

   value class Moo implements Comparable { }

   Moo m = ...
   Comparable c = m;

The most obvious answer is "boxing".  (And such boxes have a better 
chance of being eliminated via escape analysis than existing boxes, as 
they can be "heisenboxes" -- tagged as being identity-hostile and 
therefore freely unboxed/reboxed.)  Maybe this answer is OK, but maybe 
this is still too much of an attractive nuisance.

Anyway, this stuff is all swapped out right now, as we've been focusing 
quite heavily on the translation aspects of wildcards and specialized 
generic methods, so we'll return to this topic later.  Further updates 
to come....

From mikeb01 at gmail.com  Tue Aug  4 21:25:12 2015
From: mikeb01 at gmail.com (Michael Barker)
Date: Wed, 5 Aug 2015 09:25:12 +1200
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
Message-ID: <CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>

Hi John,


> 5)  return (E) entries[mapSequenceToIndex(sequence, entries.length >> 1)
> & entries.length];
>
> where the following method may or may not be hand-inlined:
>
>    static int mapSequenceToIndex(long sequence, int logicalLength) {
>       return sequence & (logicalLength-1) + BUFFER_PAD;
>    }
>
> Season to taste?  The point is that the JIT sees any random int expression,
> followed by "& entries.length", which is enough to elide the range check.
>

Thanks, I'll give that approach a try.  While it retains the padding on the
array entries it is lost for entries.length, so while it won't share a
cache line with the array entries it could share it with some other random
unknown thing.  I still have to run some more tests to see what the actual
costs end up being.  I suspect that I'll just suck up the cost of the
bounds checking, given that the Disruptor's focus is predictable latency
the overhead of a few additional instructions and an always correctly
predicted branch is probably better than occasional cache misses.

Mike.

From eliasvasylenko at gmail.com  Tue Aug  4 21:38:44 2015
From: eliasvasylenko at gmail.com (elias vasylenko)
Date: Tue, 04 Aug 2015 21:38:44 +0000
Subject: "Model 2" prototype status
In-Reply-To: <CAP7YuASd2-NPHrS5pviT35XN+OvnQg4X4kog_teH_DVJVx_SWA@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
	<CAP7YuASd2-NPHrS5pviT35XN+OvnQg4X4kog_teH_DVJVx_SWA@mail.gmail.com>
Message-ID: <CAOyefYc+36Fr2au2BA7VWC5mq6jVc+qx1t_wWuQtH7uTDK4krA@mail.gmail.com>

"we are more likely to avoid "boxing" ourselves into a corner."

Oh har har har ;).

Thanks for the replies guys, appreciated. If it's a case of not counting
your eggs until they have been more rigorously specified, and their
interactions with one another more thoroughly explored, etc., then I can
totally see where you're coming from. Soft goals need to stay soft until
the overall picture starts to come together more clearly, sure.

And of course you predicted my naive thought process quite accurately,
Brian... As you say it does seem intuitive that some manner of boxing would
happily address whatever arises, nice and simple, but yeah, I can
appreciate this is just scratching the surface! It is nice to hear you
expand a little on your general approach to and thoughts on this though,
even without diving into the real depths of it, and even if you have had
other more pressing concerns up 'til now.

At any rate, I certainly have no problem just waiting and seeing what
happens. My blind optimism will tide me over happily until these further
updates you speak of.

Thanks again for putting all this out there,

Eli

On Tue, 4 Aug 2015 at 21:33 Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi Eli,
>
> It's simply too early to tell and will need some more investigation by the
> core valhalla team, we're going to have to be patient and wait until
> they've explored this particular interaction further :-).
>
> Cheers,
> Martijn
>
> On 4 August 2015 at 21:24, elias vasylenko <eliasvasylenko at gmail.com>
> wrote:
>
>> This all sounds pretty encouraging so far to me. I feel like all my major
>> tick boxes are being steadily, if tentatively, filled. Thanks for the
>> update!
>>
>> I do have one new concern though - something you said earlier jumped out
>> at
>> me, Brian:
>>
>> "So its quite possible that Foo<any T extends Comparable> may in fact be
>> meaningful.  (And if that's the case, primitives might join the party
>> too.)  Or not, we're not sure yet."
>>
>> I suppose this must mean there is a realistic possibility that will *not*
>
>
>> in fact be meaningful, which is a surprise to me... Is this something that
>> has been discussed in more depth and I missed it? If anyone could expand
>> on
>> this a little (preferably to give a little reassurance that I'm
>> overreacting to the importance, or that the chances are low for this to
>> end
>> up being the case!) I'd be pretty relieved. It feels like it'd be a pretty
>> huge blow, and given my (limited) understanding I can't see what
>> particularly troublesome issues this even presents.
>>
>> Cheers,
>>
>> Eli
>>
>> On Sat, 1 Aug 2015 at 22:49 Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> > > I dislike the Foo<ref> / Foo<any> thing for several reasons.
>> >
>> > Not surprising.  This wasn't our first choice either.
>> >
>> > We spent a great deal of effort investigating whether it was possible to
>> > re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
>> > tvar, and to mean Foo<any> when the corresponding tvar is an any tvar.
>> > Seems obvious, right?
>> >
>> > Several hundred hours later, the short answer is that things fall apart
>> > when a library is any-fied and the client is not recompiled; this would
>> > make any-fication a binary-incompatible change, which would be a loser.
>> >   So with tears in our eyes, we reluctantly concluded that we needed to
>> > differentiate between Foo<ref> and Foo<any>.  Once we swallowed that
>> > pill, many things snapped into place.  So as sad as it is to have two
>> > kinds of wildcard, I'm pretty sure its the right call.
>> >
>> > You prefer another syntax?  Sure, I'm sure there are alternatives.  We
>> > can talk about it -- but not this year!  We have way more important
>> > things to work out before that comes anywhere near the top of the list.
>> >
>> > As to bounds...  we're still working out the details of the interaction
>> > between value types and interfaces.  So its quite possible that Foo<any
>> > T extends Comparable> may in fact be meaningful.  (And if that's the
>> > case, primitives might join the party too.)  Or not, we're not sure yet.
>> >
>> >
>> >
>>
>

From simon at ochsenreither.de  Wed Aug  5 10:39:59 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Wed, 5 Aug 2015 12:39:59 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
Message-ID: <101122742.129567.1438771199616.JavaMail.open-xchange@srv005.service.ps-server.net>

 

> I don't know why mutability of structs in .NET keeps being referred to as a
> mistake.  Sure it can lead to bugs, but so can many other things if not used
> properly.  It's a useful tool to have in some occasions (given .net supports
> passing them by ref).
> 

>From my perspective mutating value types is like changing the values inside of
Integer.IntegerCache. No need to have mutable value types when you can place
them at a writable location, especially because it wouldn't be possible to tell
anymore what code does without reading the definition of every class, like in
http://oxnrtr.de/scaladays2015/#46 .

From simon at ochsenreither.de  Wed Aug  5 10:43:58 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Wed, 5 Aug 2015 12:43:58 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
Message-ID: <63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>

But at least IDE support can help in the case of mutable structs, while the
duplicated-static-members goof-up is "by design" and can never be fixed anymore.
I would consider that issue to be much worse.
(We are planning to to this in the JVM, right?)

From moritz.schleunes at gmail.com  Wed Aug  5 11:05:00 2015
From: moritz.schleunes at gmail.com (Mo Sch)
Date: Wed, 5 Aug 2015 13:05:00 +0200
Subject: "Model 2" prototype status
In-Reply-To: <CAOyefYc+36Fr2au2BA7VWC5mq6jVc+qx1t_wWuQtH7uTDK4krA@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
	<CAP7YuASd2-NPHrS5pviT35XN+OvnQg4X4kog_teH_DVJVx_SWA@mail.gmail.com>
	<CAOyefYc+36Fr2au2BA7VWC5mq6jVc+qx1t_wWuQtH7uTDK4krA@mail.gmail.com>
Message-ID: <CAA_JsgTRgn=5nwV85niychQXo5E0+FeSVdtzsaUrPwr4FBARhQ@mail.gmail.com>

Hi,

i actually like the idea of having value types syntactical separated of ref
types. However when one happens to use any T:

Would something like this possible? (Note the for keyword would be some
syntactic sugar)

class Info<any T> implements for <ref T> InfoDeliveryRef<T>, for <val T>
InfoDeliveryVal<T> {

}

We would need to make sure that InfoDeliveryRef has the same method subset
as InfoDeliveryVal.

Also when the generic knows its type can we instantiate ref T via T t = new
T(); ?


Cheers,

Moritz

2015-08-04 23:38 GMT+02:00 elias vasylenko <eliasvasylenko at gmail.com>:

> "we are more likely to avoid "boxing" ourselves into a corner."
>
> Oh har har har ;).
>
> Thanks for the replies guys, appreciated. If it's a case of not counting
> your eggs until they have been more rigorously specified, and their
> interactions with one another more thoroughly explored, etc., then I can
> totally see where you're coming from. Soft goals need to stay soft until
> the overall picture starts to come together more clearly, sure.
>
> And of course you predicted my naive thought process quite accurately,
> Brian... As you say it does seem intuitive that some manner of boxing would
> happily address whatever arises, nice and simple, but yeah, I can
> appreciate this is just scratching the surface! It is nice to hear you
> expand a little on your general approach to and thoughts on this though,
> even without diving into the real depths of it, and even if you have had
> other more pressing concerns up 'til now.
>
> At any rate, I certainly have no problem just waiting and seeing what
> happens. My blind optimism will tide me over happily until these further
> updates you speak of.
>
> Thanks again for putting all this out there,
>
> Eli
>
> On Tue, 4 Aug 2015 at 21:33 Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
> > Hi Eli,
> >
> > It's simply too early to tell and will need some more investigation by
> the
> > core valhalla team, we're going to have to be patient and wait until
> > they've explored this particular interaction further :-).
> >
> > Cheers,
> > Martijn
> >
> > On 4 August 2015 at 21:24, elias vasylenko <eliasvasylenko at gmail.com>
> > wrote:
> >
> >> This all sounds pretty encouraging so far to me. I feel like all my
> major
> >> tick boxes are being steadily, if tentatively, filled. Thanks for the
> >> update!
> >>
> >> I do have one new concern though - something you said earlier jumped out
> >> at
> >> me, Brian:
> >>
> >> "So its quite possible that Foo<any T extends Comparable> may in fact be
> >> meaningful.  (And if that's the case, primitives might join the party
> >> too.)  Or not, we're not sure yet."
> >>
> >> I suppose this must mean there is a realistic possibility that will
> *not*
> >
> >
> >> in fact be meaningful, which is a surprise to me... Is this something
> that
> >> has been discussed in more depth and I missed it? If anyone could expand
> >> on
> >> this a little (preferably to give a little reassurance that I'm
> >> overreacting to the importance, or that the chances are low for this to
> >> end
> >> up being the case!) I'd be pretty relieved. It feels like it'd be a
> pretty
> >> huge blow, and given my (limited) understanding I can't see what
> >> particularly troublesome issues this even presents.
> >>
> >> Cheers,
> >>
> >> Eli
> >>
> >> On Sat, 1 Aug 2015 at 22:49 Brian Goetz <brian.goetz at oracle.com> wrote:
> >>
> >> > > I dislike the Foo<ref> / Foo<any> thing for several reasons.
> >> >
> >> > Not surprising.  This wasn't our first choice either.
> >> >
> >> > We spent a great deal of effort investigating whether it was possible
> to
> >> > re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
> >> > tvar, and to mean Foo<any> when the corresponding tvar is an any tvar.
> >> > Seems obvious, right?
> >> >
> >> > Several hundred hours later, the short answer is that things fall
> apart
> >> > when a library is any-fied and the client is not recompiled; this
> would
> >> > make any-fication a binary-incompatible change, which would be a
> loser.
> >> >   So with tears in our eyes, we reluctantly concluded that we needed
> to
> >> > differentiate between Foo<ref> and Foo<any>.  Once we swallowed that
> >> > pill, many things snapped into place.  So as sad as it is to have two
> >> > kinds of wildcard, I'm pretty sure its the right call.
> >> >
> >> > You prefer another syntax?  Sure, I'm sure there are alternatives.  We
> >> > can talk about it -- but not this year!  We have way more important
> >> > things to work out before that comes anywhere near the top of the
> list.
> >> >
> >> > As to bounds...  we're still working out the details of the
> interaction
> >> > between value types and interfaces.  So its quite possible that
> Foo<any
> >> > T extends Comparable> may in fact be meaningful.  (And if that's the
> >> > case, primitives might join the party too.)  Or not, we're not sure
> yet.
> >> >
> >> >
> >> >
> >>
> >
>

From martijnverburg at gmail.com  Wed Aug  5 11:33:18 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 5 Aug 2015 12:33:18 +0100
Subject: "Model 2" prototype status
In-Reply-To: <63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <CAP7YuARCkp88Mi7JDEhv1F4QOOwN1TK=b1REC3_8LdU6xjLn8w@mail.gmail.com>

Hi Simon,

On 5 August 2015 at 11:43, Simon Ochsenreither <simon at ochsenreither.de>
wrote:

> But at least IDE support can help in the case of mutable structs, while the
> duplicated-static-members goof-up is "by design" and can never be fixed
> anymore.
> I would consider that issue to be much worse.
> (We are planning to to this in the JVM, right?)
>

Did you mean "(We are planning to do this in the JVM, right?)" what do you
mean by this?

Cheers,
Martijn

From martijnverburg at gmail.com  Wed Aug  5 11:40:20 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 5 Aug 2015 12:40:20 +0100
Subject: "Model 2" prototype status
In-Reply-To: <CAA_JsgTRgn=5nwV85niychQXo5E0+FeSVdtzsaUrPwr4FBARhQ@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<CAOyefYcYO6-F2snynoR-8Gmqq_s5bfxmBg3g2Wdorht2tsvS3A@mail.gmail.com>
	<CAP7YuASd2-NPHrS5pviT35XN+OvnQg4X4kog_teH_DVJVx_SWA@mail.gmail.com>
	<CAOyefYc+36Fr2au2BA7VWC5mq6jVc+qx1t_wWuQtH7uTDK4krA@mail.gmail.com>
	<CAA_JsgTRgn=5nwV85niychQXo5E0+FeSVdtzsaUrPwr4FBARhQ@mail.gmail.com>
Message-ID: <CAP7YuATOaRQtOn5Vy8NyagHbmRJPwef_NjwirOFZewCkh4VAHw@mail.gmail.com>

Hi Moritz,

The various combinations are still being explored. Can you give the
existing prototype a go and send in your use cases where it doesn't meet
your needs?

Cheers,
Martijn

On 5 August 2015 at 12:05, Mo Sch <moritz.schleunes at gmail.com> wrote:

> Hi,
>
> i actually like the idea of having value types syntactical separated of ref
> types. However when one happens to use any T:
>
> Would something like this possible? (Note the for keyword would be some
> syntactic sugar)
>
> class Info<any T> implements for <ref T> InfoDeliveryRef<T>, for <val T>
> InfoDeliveryVal<T> {
>
> }
>
> We would need to make sure that InfoDeliveryRef has the same method subset
> as InfoDeliveryVal.
>
> Also when the generic knows its type can we instantiate ref T via T t = new
> T(); ?
>
>
> Cheers,
>
> Moritz
>
> 2015-08-04 23:38 GMT+02:00 elias vasylenko <eliasvasylenko at gmail.com>:
>
> > "we are more likely to avoid "boxing" ourselves into a corner."
> >
> > Oh har har har ;).
> >
> > Thanks for the replies guys, appreciated. If it's a case of not counting
> > your eggs until they have been more rigorously specified, and their
> > interactions with one another more thoroughly explored, etc., then I can
> > totally see where you're coming from. Soft goals need to stay soft until
> > the overall picture starts to come together more clearly, sure.
> >
> > And of course you predicted my naive thought process quite accurately,
> > Brian... As you say it does seem intuitive that some manner of boxing
> would
> > happily address whatever arises, nice and simple, but yeah, I can
> > appreciate this is just scratching the surface! It is nice to hear you
> > expand a little on your general approach to and thoughts on this though,
> > even without diving into the real depths of it, and even if you have had
> > other more pressing concerns up 'til now.
> >
> > At any rate, I certainly have no problem just waiting and seeing what
> > happens. My blind optimism will tide me over happily until these further
> > updates you speak of.
> >
> > Thanks again for putting all this out there,
> >
> > Eli
> >
> > On Tue, 4 Aug 2015 at 21:33 Martijn Verburg <martijnverburg at gmail.com>
> > wrote:
> >
> > > Hi Eli,
> > >
> > > It's simply too early to tell and will need some more investigation by
> > the
> > > core valhalla team, we're going to have to be patient and wait until
> > > they've explored this particular interaction further :-).
> > >
> > > Cheers,
> > > Martijn
> > >
> > > On 4 August 2015 at 21:24, elias vasylenko <eliasvasylenko at gmail.com>
> > > wrote:
> > >
> > >> This all sounds pretty encouraging so far to me. I feel like all my
> > major
> > >> tick boxes are being steadily, if tentatively, filled. Thanks for the
> > >> update!
> > >>
> > >> I do have one new concern though - something you said earlier jumped
> out
> > >> at
> > >> me, Brian:
> > >>
> > >> "So its quite possible that Foo<any T extends Comparable> may in fact
> be
> > >> meaningful.  (And if that's the case, primitives might join the party
> > >> too.)  Or not, we're not sure yet."
> > >>
> > >> I suppose this must mean there is a realistic possibility that will
> > *not*
> > >
> > >
> > >> in fact be meaningful, which is a surprise to me... Is this something
> > that
> > >> has been discussed in more depth and I missed it? If anyone could
> expand
> > >> on
> > >> this a little (preferably to give a little reassurance that I'm
> > >> overreacting to the importance, or that the chances are low for this
> to
> > >> end
> > >> up being the case!) I'd be pretty relieved. It feels like it'd be a
> > pretty
> > >> huge blow, and given my (limited) understanding I can't see what
> > >> particularly troublesome issues this even presents.
> > >>
> > >> Cheers,
> > >>
> > >> Eli
> > >>
> > >> On Sat, 1 Aug 2015 at 22:49 Brian Goetz <brian.goetz at oracle.com>
> wrote:
> > >>
> > >> > > I dislike the Foo<ref> / Foo<any> thing for several reasons.
> > >> >
> > >> > Not surprising.  This wasn't our first choice either.
> > >> >
> > >> > We spent a great deal of effort investigating whether it was
> possible
> > to
> > >> > re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
> > >> > tvar, and to mean Foo<any> when the corresponding tvar is an any
> tvar.
> > >> > Seems obvious, right?
> > >> >
> > >> > Several hundred hours later, the short answer is that things fall
> > apart
> > >> > when a library is any-fied and the client is not recompiled; this
> > would
> > >> > make any-fication a binary-incompatible change, which would be a
> > loser.
> > >> >   So with tears in our eyes, we reluctantly concluded that we needed
> > to
> > >> > differentiate between Foo<ref> and Foo<any>.  Once we swallowed that
> > >> > pill, many things snapped into place.  So as sad as it is to have
> two
> > >> > kinds of wildcard, I'm pretty sure its the right call.
> > >> >
> > >> > You prefer another syntax?  Sure, I'm sure there are alternatives.
> We
> > >> > can talk about it -- but not this year!  We have way more important
> > >> > things to work out before that comes anywhere near the top of the
> > list.
> > >> >
> > >> > As to bounds...  we're still working out the details of the
> > interaction
> > >> > between value types and interfaces.  So its quite possible that
> > Foo<any
> > >> > T extends Comparable> may in fact be meaningful.  (And if that's the
> > >> > case, primitives might join the party too.)  Or not, we're not sure
> > yet.
> > >> >
> > >> >
> > >> >
> > >>
> > >
> >
>

From timo.kinnunen at gmail.com  Wed Aug  5 11:08:15 2015
From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=)
Date: Wed, 5 Aug 2015 11:08:15 +0000
Subject: =?utf-8?Q?Re:_"Model_2"_prototype_status?=
In-Reply-To: <63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>,
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>

Hi, 


What is the goof-up? I can see duplication of static members having several benefits. Off the top of my head:


1) It makes it possible to implement a statically type-safe Collections.emptyList().

2) Adding language support for type-safe generic constants becomes a relatively small addition.

3) It means specializations can have the same lifetimes as their consumers have, meaning they can live within the caller?s classloader rather than being associated with some global registry.


That last point means more opportunities for class unloading, for instance. It also prevents a whole category of bugs -- those triggered when the order classes are loaded changes invisibly -- from arising for specialized types or methods or fields.




-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Simon Ochsenreither
Sent: ?Wednesday?, ?August? ?5?, ?2015 ?12?:?43
To: Vitaly Davidovich
Cc: valhalla-dev at openjdk.java.net





But at least IDE support can help in the case of mutable structs, while the
duplicated-static-members goof-up is "by design" and can never be fixed anymore.
I would consider that issue to be much worse.
(We are planning to to this in the JVM, right?)

From vitalyd at gmail.com  Wed Aug  5 12:47:45 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 5 Aug 2015 08:47:45 -0400
Subject: "Model 2" prototype status
In-Reply-To: <101122742.129567.1438771199616.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<101122742.129567.1438771199616.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <CAHjP37HtBkVMR0q18ueT0-28pUnLvxvAffWgDujVWorp0m0yFg@mail.gmail.com>

There's also a practical view: value types are fixed size typed blobs on
stack or offset within heap object and that blob can have its content
changed.  Ints can also be mutated by passing them by ref; this is useful
for simulating multi return values.  If I want to bundle 64 bytes of
mutable data together and pass it across several call frames or have them
laid out in an array and don't want to pay copy costs each time, this is
very practically useful.  You can also create iterators, builders, and
other little abstractions that stay on the call stack without relying on
JIT to elide copies.  You can use them for native interop and have native
code directly manipulate them.

sent from my phone
On Aug 5, 2015 6:40 AM, "Simon Ochsenreither" <simon at ochsenreither.de>
wrote:

>
>
> I don't know why mutability of structs in .NET keeps being referred to as
> a mistake.  Sure it can lead to bugs, but so can many other things if not
> used properly.  It's a useful tool to have in some occasions (given .net
> supports passing them by ref).
>
> From my perspective mutating value types is like changing the values
> inside of Integer.IntegerCache. No need to have mutable value types when
> you can place them at a writable location, especially because it wouldn't
> be possible to tell anymore what code does without reading the definition
> of every class, like in http://oxnrtr.de/scaladays2015/#46 .
>

From vitalyd at gmail.com  Wed Aug  5 12:50:52 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 5 Aug 2015 08:50:52 -0400
Subject: "Model 2" prototype status
In-Reply-To: <55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
Message-ID: <CAHjP37FnMaEENtAe4CkoTEXc0L1JmG4W2u0JgNB7szZ9e8g1-w@mail.gmail.com>

I agree that I don't consider it a goof up either.  The generic type is a
recipe/template, and specialization should create its own state.  If that's
an issue, then create a base non-generic class and move static fields you
don't want to replicate there.

sent from my phone
On Aug 5, 2015 7:55 AM, "Timo Kinnunen" <timo.kinnunen at gmail.com> wrote:

> Hi,
>
> What is the goof-up? I can see duplication of static members having
> several benefits. Off the top of my head:
>
> 1) It makes it possible to implement a statically type-safe
> Collections.emptyList().
> 2) Adding language support for type-safe generic constants becomes a
> relatively small addition.
> 3) It means specializations can have the same lifetimes as their consumers
> have, meaning they can live within the caller?s classloader rather than
> being associated with some global registry.
>
> That last point means more opportunities for class unloading, for
> instance. It also prevents a whole category of bugs -- those triggered when
> the order classes are loaded changes invisibly -- from arising for
> specialized types or methods or fields.
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
> *From:* Simon Ochsenreither <simon at ochsenreither.de>
> *Sent:* ?Wednesday?, ?August? ?5?, ?2015 ?12?:?43
> *To:* Vitaly Davidovich <vitalyd at gmail.com>
> *Cc:* valhalla-dev at openjdk.java.net
>
> But at least IDE support can help in the case of mutable structs, while the
> duplicated-static-members goof-up is "by design" and can never be fixed
> anymore.
> I would consider that issue to be much worse.
> (We are planning to to this in the JVM, right?)
>

From dl at cs.oswego.edu  Wed Aug  5 14:12:43 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 05 Aug 2015 10:12:43 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
Message-ID: <55C219DB.2090104@cs.oswego.edu>

On 08/04/2015 05:25 PM, Michael Barker wrote:

> Thanks, I'll give that approach a try.  While it retains the padding on the
> array entries it is lost for entries.length, so while it won't share a
> cache line with the array entries it could share it with some other random
> unknown thing.  I still have to run some more tests to see what the actual
> costs end up being.  I suspect that I'll just suck up the cost of the
> bounds checking,

That's what I've ended up doing in similar cases in java.util.concurrent.
It does add variance depending on placement across runs of
programs as well as within runs when GC moves things. But not
much more variance than you see from other memory placement
effects and JVM noise.

It's worth reminding everyone that the need to do this
stems from compiler limitations that in principle could
be addressed someday. "Unsafe" access just means that
the compiler cannot prove that an address is legal.
It is frustrating that some cases that are obvious
to their programmers cannot be proven -- as in an array
that is only ever allocated with power-of-two size and
accessed with masked indexing, but the allocation is outside
the scope of compiler analysis.

High-quality bounds-check optimizations generally require
internal type systems and static analyses that are too
expensive for JITs. (See for example the work done in the
ahead-of-time X10 compiler.) But with the planned demise
of Unsafe, perhaps some people interested in optimization
will be more motivated to try to invent some more effective
JIT-friendly approximations.

-Doug



From vitalyd at gmail.com  Wed Aug  5 14:20:45 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 5 Aug 2015 10:20:45 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <55C219DB.2090104@cs.oswego.edu>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
Message-ID: <CAHjP37EYWE5TtqHFL1dS5USS-vFW39+anQ83DOKkiTbv+YEUmw@mail.gmail.com>

>
> High-quality bounds-check optimizations generally require
> internal type systems and static analyses that are too
> expensive for JITs. (See for example the work done in the
> ahead-of-time X10 compiler.) But with the planned demise
> of Unsafe, perhaps some people interested in optimization
> will be more motivated to try to invent some more effective
> JIT-friendly approximations.


If Vladimir Ivanov's research into constant folding finals works out, then
presumably at JIT time compiler can look at the values of array.length and
the mask and handle the 2^n cases, assuming both the array and mask are
final (not always the case, but would cover a good number of use cases).
However, there will always be things the compiler cannot/doesn't do, and in
those cases it's nice to have things like Unsafe to fall back on.


On Wed, Aug 5, 2015 at 10:12 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 08/04/2015 05:25 PM, Michael Barker wrote:
>
> Thanks, I'll give that approach a try.  While it retains the padding on the
>> array entries it is lost for entries.length, so while it won't share a
>> cache line with the array entries it could share it with some other random
>> unknown thing.  I still have to run some more tests to see what the actual
>> costs end up being.  I suspect that I'll just suck up the cost of the
>> bounds checking,
>>
>
> That's what I've ended up doing in similar cases in java.util.concurrent.
> It does add variance depending on placement across runs of
> programs as well as within runs when GC moves things. But not
> much more variance than you see from other memory placement
> effects and JVM noise.
>
> It's worth reminding everyone that the need to do this
> stems from compiler limitations that in principle could
> be addressed someday. "Unsafe" access just means that
> the compiler cannot prove that an address is legal.
> It is frustrating that some cases that are obvious
> to their programmers cannot be proven -- as in an array
> that is only ever allocated with power-of-two size and
> accessed with masked indexing, but the allocation is outside
> the scope of compiler analysis.
>
> High-quality bounds-check optimizations generally require
> internal type systems and static analyses that are too
> expensive for JITs. (See for example the work done in the
> ahead-of-time X10 compiler.) But with the planned demise
> of Unsafe, perhaps some people interested in optimization
> will be more motivated to try to invent some more effective
> JIT-friendly approximations.
>
> -Doug
>
>
>

From brian.goetz at oracle.com  Wed Aug  5 20:15:14 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Wed, 05 Aug 2015 20:15:14 +0000
Subject: hg: valhalla/valhalla/jdk: More stream factories;
	initial stab at slice ops and stateteful parallel pipeline rewriting
	(not yet working)
Message-ID: <201508052015.t75KFEOx016194@aojmv0008.oracle.com>

Changeset: f4b950361943
Author:    briangoetz
Date:      2015-08-05 16:15 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f4b950361943

More stream factories; initial stab at slice ops and stateteful parallel pipeline rewriting (not yet working)

! src/java.base/share/classes/java/anyutil/stream/DoubleStream.java
! src/java.base/share/classes/java/anyutil/stream/IntStream.java
! src/java.base/share/classes/java/anyutil/stream/LongStream.java
! src/java.base/share/classes/java/anyutil/stream/Pipeline.java
+ src/java.base/share/classes/java/anyutil/stream/SliceOps.java
! src/java.base/share/classes/java/anyutil/stream/Stream.java
! src/java.base/share/classes/java/anyutil/stream/StreamSpliterators.java
! src/java.base/share/classes/java/anyutil/stream/Streams.java
! test/valhalla/test/valhalla/anyutil/SimplePipelineTest.java


From simon at ochsenreither.de  Thu Aug  6 16:56:35 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Thu, 6 Aug 2015 18:56:35 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>,
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
Message-ID: <1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>

I'm not saying that duplicating static members is without benefits, especially
when it comes to ease of implementation.
 
The problem with this approach is that it vastly complicates the mental model of
everyone learning or using Java.
Today, people have to distinguish between members which are per-class and
members which are per-instance.
 
(Java doesn't separate these members, but allows mixing them freely at
declaration site. From my experience with beginners learning to program, this is
pretty bad already.)
 
With duplicated members, we would put the implementation details of specialized
classes right in front of users, and force them to learn another layer.
We would have
- members per class without class-level Generics or with erased Generics
- members per specialized class artifact of a class with reified Generics
- members per instance
 
This is especially confusing given that the duplicated fields would only exist
for value types, while reference types would share the same member.
 
I've spent a lot of time in Scala working to remove things where people said
"oh, you just need to spend 5 minutes learning it, and then it will be fine!".
Duplicated statics is certainly not a 5 minute tax on every present or future
Java developer, it's probably a magnitude more.

From vitalyd at gmail.com  Thu Aug  6 17:26:41 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 6 Aug 2015 13:26:41 -0400
Subject: "Model 2" prototype status
In-Reply-To: <1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>

Quite frankly, these are java/jvm issues -- in .NET there's no
inconsistency such as

This is especially confusing given that the duplicated fields would only
> exist for value types, while reference types would share the same member.


My initial objection was about the comment that .NET goofed up, which I
disagree with; whether something different needs to be done for java to
maintain backcompat is a different (and likely) story.

I've spent a lot of time in Scala working to remove things where people
> said "oh, you just need to spend 5 minutes learning it, and then it will be
> fine!".
> Duplicated statics is certainly not a 5 minute tax on every present or
> future Java developer, it's probably a magnitude more.


If the system is self inconsistent (your example of duplicated fields on
value types vs ref types), then yes, that's bad.  Otherwise, it bugs me
that there's some sentiment that java developers are somehow incapable of
learning anything "advanced", however you define that (I've seen this type
of view expressed many times on this list and elsewhere).  I've never
seen/heard of anyone complaining about how CLR handles static fields on
generic types.  There are far more involved concepts that a java developer
needs to become familiar with.  If one wants to be beginner friendly, then
provide good documentation, examples, community, etc around the language
rather than somehow dumbing the language down.

On Thu, Aug 6, 2015 at 12:56 PM, Simon Ochsenreither <simon at ochsenreither.de
> wrote:

> I'm not saying that duplicating static members is without benefits,
> especially when it comes to ease of implementation.
>
> The problem with this approach is that it vastly complicates the mental
> model of everyone learning or using Java.
> Today, people have to distinguish between members which are per-class and
> members which are per-instance.
>
> (Java doesn't separate these members, but allows mixing them freely at
> declaration site. From my experience with beginners learning to program,
> this is pretty bad already.)
>
> With duplicated members, we would put the implementation details of
> specialized classes right in front of users, and force them to learn
> another layer.
> We would have
> - members per class without class-level Generics or with erased Generics
> - members per specialized class artifact of a class with reified Generics
> - members per instance
>
> This is especially confusing given that the duplicated fields would only
> exist for value types, while reference types would share the same member.
>
> I've spent a lot of time in Scala working to remove things where people
> said "oh, you just need to spend 5 minutes learning it, and then it will be
> fine!".
> Duplicated statics is certainly not a 5 minute tax on every present or
> future Java developer, it's probably a magnitude more.
>

From simon at ochsenreither.de  Thu Aug  6 18:30:38 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Thu, 6 Aug 2015 20:30:38 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
Message-ID: <1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>

 

>    > > This is especially confusing given that the duplicated fields would
>    > > only exist for value types, while reference types would share the same
>    > > member.
> >  >   
>  My initial objection was about the comment that .NET goofed up, which I
> disagree with; whether something different needs to be done for java to
> maintain backcompat is a different (and likely) story.
> 

But then I think the argument about tying the lifetime of these statics to the
class artifact backing it is moot, isn't it?

Plus, this would be yet-another thing which would work slightly different and
expose implementation details to the user.

>   
>    > > I've spent a lot of time in Scala working to remove things where people
>    > > said "oh, you just need to spend 5 minutes learning it, and then it
>    > > will be fine!".
> >    Duplicated statics is certainly not a 5 minute tax on every present or
> > future Java developer, it's probably a magnitude more.
> >  > 

>  Otherwise, it bugs me that there's some sentiment that java developers are
> somehow incapable of learning anything "advanced", however you define that
> (I've seen this type of view expressed many times on this list and elsewhere).
>  I've never seen/heard of anyone complaining about how CLR handles static
> fields on generic types.  There are far more involved concepts that a java
> developer needs to become familiar with.  If one wants to be beginner
> friendly, then provide good documentation, examples, community, etc around the
> language rather than somehow dumbing the language down.
> 

I'm not sure how you get that impression from my reply. What I'm arguing against
is the notion that the ease of implementation for the compiler/language/runtime
author is more important than the time of developers. I don't question that
people can sit down and learn things, but I question the need for them to do
that in every case if a better design could have prevented that.

If every implementer says "ironing out the odd corners and inconsistencies of my
language feature is too much work, let the user deal with it", then we will have
a language which takes a lot of unwarranted time to learn. It's a bit like
non-metric systems. Sure, it's possible to learn them, but it's 2015, and people
ought to have better things to do than deal with inches and foots.

Of course there are more involved concepts, and of course documentation,
examples, community can help, but not having to support people learning the
quirks ? because there are no quirks ? is a superior approach in my opinion.

>From my point of view the question is "do we want to waste developer's time by
unnecessarily complicating the mental model of classes and instances?".

From vitalyd at gmail.com  Thu Aug  6 18:54:01 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 6 Aug 2015 14:54:01 -0400
Subject: "Model 2" prototype status
In-Reply-To: <1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>

>
> But then I think the argument about tying the lifetime of these statics to
> the class artifact backing it is moot, isn't it?
> Plus, this would be yet-another thing which would work slightly different
> and expose implementation details to the user.


I suspect there's miscommunication.  I'm not saying that .NET's model is
appropriate for java today, I was only addressing the comment that .NET
somehow messed up by replicating static fields across instantiations of
generic types.

What I'm arguing against is the notion that the ease of implementation for
> the compiler/language/runtime author is more important than the time of
> developers. I don't question that people can sit down and learn things, but
> I question the need for them to do that in every case if a better design
> could have prevented that.


I agree in principle.  "Better design" is subjective and context dependent
though.  What is the better design you have in mind?

On Thu, Aug 6, 2015 at 2:30 PM, Simon Ochsenreither <simon at ochsenreither.de>
wrote:

>
>
>
> This is especially confusing given that the duplicated fields would only
> exist for value types, while reference types would share the same member.
>
>
> My initial objection was about the comment that .NET goofed up, which I
> disagree with; whether something different needs to be done for java to
> maintain backcompat is a different (and likely) story.
>
> But then I think the argument about tying the lifetime of these statics to
> the class artifact backing it is moot, isn't it?
>
> Plus, this would be yet-another thing which would work slightly different
> and expose implementation details to the user.
>
>
>
> I've spent a lot of time in Scala working to remove things where people
> said "oh, you just need to spend 5 minutes learning it, and then it will be
> fine!".
> Duplicated statics is certainly not a 5 minute tax on every present or
> future Java developer, it's probably a magnitude more.
>
> Otherwise, it bugs me that there's some sentiment that java developers are
> somehow incapable of learning anything "advanced", however you define that
> (I've seen this type of view expressed many times on this list and
> elsewhere).  I've never seen/heard of anyone complaining about how CLR
> handles static fields on generic types.  There are far more involved
> concepts that a java developer needs to become familiar with.  If one wants
> to be beginner friendly, then provide good documentation, examples,
> community, etc around the language rather than somehow dumbing the language
> down.
>
> I'm not sure how you get that impression from my reply. What I'm arguing
> against is the notion that the ease of implementation for the
> compiler/language/runtime author is more important than the time of
> developers. I don't question that people can sit down and learn things, but
> I question the need for them to do that in every case if a better design
> could have prevented that.
>
> If every implementer says "ironing out the odd corners and inconsistencies
> of my language feature is too much work, let the user deal with it", then
> we will have a language which takes a lot of unwarranted time to learn.
> It's a bit like non-metric systems. Sure, it's possible to learn them, but
> it's 2015, and people ought to have better things to do than deal with
> inches and foots.
>
> Of course there are more involved concepts, and of course documentation,
> examples, community can help, but not having to support people learning the
> quirks ? because there are no quirks ? is a superior approach in my opinion.
>
> From my point of view the question is "do we want to waste developer's
> time by unnecessarily complicating the mental model of classes and
> instances?".
>

From forax at univ-mlv.fr  Thu Aug  6 20:30:51 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 06 Aug 2015 20:30:51 +0000
Subject: "Model 2" prototype status
In-Reply-To: <1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>,
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <030A8584-9996-4362-A151-747D5FDE5E02@univ-mlv.fr>



Le 6 ao?t 2015 18:56:35 CEST, Simon Ochsenreither <simon at ochsenreither.de> a ?crit :
>I'm not saying that duplicating static members is without benefits,
>especially
>when it comes to ease of implementation.
> 
>The problem with this approach is that it vastly complicates the mental
>model of
>everyone learning or using Java.
>Today, people have to distinguish between members which are per-class
>and
>members which are per-instance.
> 
>(Java doesn't separate these members, but allows mixing them freely at
>declaration site. From my experience with beginners learning to
>program, this is
>pretty bad already.)

yes, it's bad and an usual issue unless you introduce static after 5 or 6 weeks courses.

but accessing to a field or a local variable with the same syntax is far worth IMO.

> 
>With duplicated members, we would put the implementation details of
>specialized
>classes right in front of users, and force them to learn another layer.
>We would have
>- members per class without class-level Generics or with erased
>Generics
>- members per specialized class artifact of a class with reified
>Generics
>- members per instance
> 
>This is especially confusing given that the duplicated fields would
>only exist
>for value types, while reference types would share the same member.
> 
>I've spent a lot of time in Scala working to remove things where people
>said
>"oh, you just need to spend 5 minutes learning it, and then it will be
>fine!".
>Duplicated statics is certainly not a 5 minute tax on every present or
>future
>Java developer, it's probably a magnitude more.

R?mi 



From timo.kinnunen at gmail.com  Fri Aug  7 00:02:08 2015
From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com)
Date: Fri, 7 Aug 2015 02:02:08 +0200
Subject: "Model 2" prototype status
In-Reply-To: <1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>,
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <55c3f585.0d3dc20a.7732.ffffbfbf@mx.google.com>

I suppose it depends on how the mental model is constructed. The worst way would be to look at some implementation, see that it uses the same primitive to implement both per-instance members and per-class members and from that draw a conclusion that they are both essentially the same thing.

Per-instance members have an existence independent of whoever is calling into them right now, whereas per-class members have none until someone calling into them gives them one. This is a pretty big difference and finding a shortcut to explain it away doesn?t sound like a good idea to me.

Instead, perhaps a better mental model would say something like:
- There exists one instance member for each instance that?s been created.
- There exists one class member for every different type (specialization) that uses it.
- As a special case, when the type of the user of the static member isn?t available or needed, then the type is considered to be java.lang.Object. This is where we are now.

Are we still thinking about static members the same way we did in the pre-Generics days? ?





Sent from Mail for Windows 10



From: Simon Ochsenreither
Sent: Thursday, August 6, 2015 18:56
To: Vitaly Davidovich;Timo Kinnunen
Cc: valhalla-dev at openjdk.java.net
Subject: Re: "Model 2" prototype status


I'm not saying that duplicating static members is without benefits, especially when it comes to ease of implementation.
?
The problem with this approach is that it vastly complicates the mental model of everyone learning or using Java.
Today, people have to distinguish between members which are per-class and members which are per-instance.
?
(Java doesn't separate these members, but allows mixing them freely at declaration site. From my experience with beginners learning to program, this is pretty bad already.)
?
With duplicated members, we would put the implementation details of specialized classes right in front of users, and force them to learn another layer.
We would have
- members per class without class-level Generics or with erased Generics
- members per specialized class artifact of a class with reified Generics
- members per instance
?
This is especially confusing given that the duplicated fields would only exist for value types, while reference types would share the same member.
?
I've spent a lot of time in Scala working to remove things where people said "oh, you just need to spend 5 minutes learning it, and then it will be fine!".
Duplicated statics is certainly not a 5 minute tax on every present or future Java developer, it's probably a magnitude more.



From vlad.ureche at gmail.com  Fri Aug  7 15:17:17 2015
From: vlad.ureche at gmail.com (Vlad Ureche)
Date: Fri, 7 Aug 2015 17:17:17 +0200
Subject: "Model 2" prototype implementation
Message-ID: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>

Hi everyone,

I?m opening a new thread, since "Model 2" prototype status went in the
syntax and semantics direction and I don?t want to derail it. First of all,
this is very exciting news and it will make translating Scala code to
Valhalla quite straight-forward (except for a few acceptable restrictions).

I?m wondering how will the implementation work?
Specifically, in this example, which assumes a specialized Box class defined
here
<web.archive.org/web/20150801070114/http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html#erasure-example-a-simple-box-class>
:

Box<int> box = new Box<int>(4);
Box<any> box_any = box;

// what does get() return? and how does it return it?
System.out.println(box_any.get());

// even more interesting, how does this work:
System.out.println(box_any.t /* assuming the box value is visible */);

How do you translate the method calls and field accesses? Do they return
boxed values?

Thanks,
Vlad

PS: Shameless advertising ? I recently worked on a paper describing the
pitfalls I?ve encountered in miniboxing <http://scala-miniboxing.org> when
using erased views (and specialized views) and how to mitigate them, which
has been accepted for PPPJ 2015. In case you?re interested, an earlier
draft is available here <http://infoscience.epfl.ch/record/208797?ln=en>.
?

From brian.goetz at oracle.com  Fri Aug  7 15:49:31 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 11:49:31 -0400
Subject: "Model 2" prototype implementation
In-Reply-To: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
Message-ID: <55C4D38B.4060503@oracle.com>

Great question.  We're working on a writeup of the translation details; 
we announced the prototype before the writeup was ready, because we 
didn't want to keep early adopters from trying it out any further, but 
there's a writeup coming.

Here's a very brief taste (but you'll have to wait for the writeup, or 
use javap on the output of javac, for more).  Imagine the function

    R : Type -> Class

which maps a compile-time type to a runtime class.  In Java 5 generics, 
for a class Foo<T>, the R mapping is very simple -- everything is erased:

R(Foo<String>) = Foo
R(Foo<?>) = Foo
R(Foo) = Foo

In Valhalla, for a class Foo<any T>, the mapping is more complex:

Compatibility demands we adopt the above mappings:
R(Foo<String>) = Foo
R(Foo<ref>) = Foo
R(Foo<raw>) = Foo

And we get some new ones:
R(Foo<int>) = Foo${0=I} *
R(Foo<any>) = Foo$any **

*Name mangling is temporary; something better is in the works.
**Foo$any is a synthetic *interface* generated by javac, which can be 
implemented by Foo<int> and Foo<String> alike (using boxing in the API 
where necessary).

Because Foo$any is an interface, it can't have fields.  So we lift the 
fields of Foo to (possibly boxing) accessors on Foo$any (VM help is 
needed for nonpublic members here), and we convert field accesses 
(through receivers of type Foo<any> only!) to invocations of those 
accessors.  (Field access through concretely-typed receivers 
(Foo<String> or Foo<int>) are still translated with straight 
getfield/putfield, so the boxing penalty is only paid by wildcard users.)

Here's your example:

     public static void main(String[] args) {
         Box<int> box = new Box<int>(3);
         Box<any> box_any = box;
         System.out.println(box_any.get());
         System.out.println(box_any.t);
     }

And the bytecode (which works as expected):

public static void main(java.lang.String[]);
     Code:
        0: new           #2                  // class "Box${0=I}"
        3: dup
        4: iconst_3
        5: invokespecial #3                  // Method 
"Box${0=I}"."<init>":(I)V
        8: astore_1
        9: aload_1
       10: astore_2
       11: getstatic     #4                  // Field 
java/lang/System.out:Ljava/io/PrintStream;
       14: aload_2
       15: invokedynamic #5,  0              // InvokeDynamic 
#0:get:(LBox$$any;)Ljava/lang/Object;
       20: invokevirtual #6                  // Method 
java/io/PrintStream.println:(Ljava/lang/Object;)V
       23: getstatic     #4                  // Field 
java/lang/System.out:Ljava/io/PrintStream;
       26: aload_2
       27: invokedynamic #7,  0              // InvokeDynamic 
#1:t$get:(LBox$$any;)Ljava/lang/Object;
       32: invokevirtual #6                  // Method 
java/io/PrintStream.println:(Ljava/lang/Object;)V
       35: return

BootstrapMethods:
   0: #26 invokestatic 
java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
     Method arguments:
       #27 invokeinterface Box$$any.get:()Ljava/lang/Object;
   1: #26 invokestatic 
java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
     Method arguments:
       #31 invokeinterface Box$$any.t$get:()Ljava/lang/Object;

The invokedynamic at bci=15 and 27 invoke the get() and t$get() methods 
of the Foo$any interface.  We use invokedynamic instead of 
invokeinterface because it allows us to do some boxing adaptations more 
easily than statically generating yet more bridge methods.  (The 
VirtualAccess bootstrap simply does a MethodHandle.asType adaptation of 
the provided MH; in the current program, there is no difference in the 
signatures so it's as if we did an invokeinterface of Box$$any.get() or 
.t$get() directly.)


> I?m wondering how will the implementation work?
> Specifically, in this example, which assumes a specialized |Box| class
> defined here
> <web.archive.org/web/20150801070114/http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html#erasure-example-a-simple-box-class>:
>
> |Box<int> box = new Box<int>(4); Box<any> box_any = box; // what does
> get() return? and how does it return it?
> System.out.println(box_any.get()); // even more interesting, how does
> this work: System.out.println(box_any.t /* assuming the box value is
> visible */); |
>
> How do you translate the method calls and field accesses? Do they return
> boxed values?
>
> Thanks,
> Vlad
>
> PS: Shameless advertising ? I recently worked on a paper describing the
> pitfalls I?ve encountered in miniboxing <http://scala-miniboxing.org>
> when using erased views (and specialized views) and how to mitigate
> them, which has been accepted for PPPJ 2015. In case you?re interested,
> an earlier draft is available here
> <http://infoscience.epfl.ch/record/208797?ln=en>.
>
> ?

From simon at ochsenreither.de  Fri Aug  7 16:15:40 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Fri, 7 Aug 2015 18:15:40 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
Message-ID: <860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>

>    > > What I'm arguing against is the notion that the ease of implementation
>    > > for the compiler/language/runtime author is more important than the
>    > > time of developers. I don't question that people can sit down and learn
>    > > things, but I question the need for them to do that in every case if a
>    > > better design could have prevented that.
> >  >   
>  I agree in principle.  "Better design" is subjective and context dependent
> though.  What is the better design you have in mind?
> 

I think keeping static fields per-class (in the sense of "the class the user
wrote down in code", not "some random class artefact the runtime happened to
emit") would be the most sensible and simple thing to do. No explanation or
learning necessary, because everything works exactly like it has the last 15
years in Java.

From brian.goetz at oracle.com  Fri Aug  7 16:37:37 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 12:37:37 -0400
Subject: "Model 2" prototype status
In-Reply-To: <860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <55BBD188.8020406@oracle.com> <55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <55C4DED1.6000801@oracle.com>

I don't see that there's any other sensible choice.  Asking users to 
reason about the partially-heterogeneous translation (where some 
instantiations share a class and some do not) in the context of an 
existing language feature like static fields would be silly -- and 
counterproductive.

(There are other places where the translation will necessarily intrude; 
ideally, we want to keep those to reflective features, those that cut 
across the language-level type system and the runtime class system, such 
as class literals (Foo.class), instanceof, casting, and reflection.)

> I think keeping static fields per-class (in the sense of "the class the user
> wrote down in code", not "some random class artefact the runtime happened to
> emit") would be the most sensible and simple thing to do. No explanation or
> learning necessary, because everything works exactly like it has the last 15
> years in Java.


From vitalyd at gmail.com  Fri Aug  7 16:46:41 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Aug 2015 12:46:41 -0400
Subject: "Model 2" prototype status
In-Reply-To: <55C4DED1.6000801@oracle.com>
References: <55BBD188.8020406@oracle.com> <55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
Message-ID: <CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>

I'd like to be able to express the following:

class Foo<T> {
    static final T _t = ...;
    static final Foo<T> _ft = ...;
}

I guess that's out?

On Fri, Aug 7, 2015 at 12:37 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I don't see that there's any other sensible choice.  Asking users to
> reason about the partially-heterogeneous translation (where some
> instantiations share a class and some do not) in the context of an existing
> language feature like static fields would be silly -- and counterproductive.
>
> (There are other places where the translation will necessarily intrude;
> ideally, we want to keep those to reflective features, those that cut
> across the language-level type system and the runtime class system, such as
> class literals (Foo.class), instanceof, casting, and reflection.)
>
>
> I think keeping static fields per-class (in the sense of "the class the
>> user
>> wrote down in code", not "some random class artefact the runtime happened
>> to
>> emit") would be the most sensible and simple thing to do. No explanation
>> or
>> learning necessary, because everything works exactly like it has the last
>> 15
>> years in Java.
>>
>
>

From brian.goetz at oracle.com  Fri Aug  7 16:54:09 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 12:54:09 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
	<CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
Message-ID: <55C4E2B1.90507@oracle.com>

Depends what you mean by out.  We are fully aware that this is a 
desirable and useful thing to be able to express, and intend to find a 
way to do so.  But we don't think that complicating the semantics of 
statics is necessarily the right way to get there.  It has been 
suggested (thanks Peter) that borrowing the "object" notion from Scala 
would be a far better way to achieve this (and other things) than to 
change the semantics of static, and I'm inclined to agree.

So the code below is probably "out" as written -- but that doesn't mean 
we've given up on solving the underlying problem.




On 8/7/2015 12:46 PM, Vitaly Davidovich wrote:
> I'd like to be able to express the following:
>
> class Foo<T> {
>      static final T _t = ...;
>      static final Foo<T> _ft = ...;
> }
>
> I guess that's out?
>
> On Fri, Aug 7, 2015 at 12:37 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     I don't see that there's any other sensible choice.  Asking users to
>     reason about the partially-heterogeneous translation (where some
>     instantiations share a class and some do not) in the context of an
>     existing language feature like static fields would be silly -- and
>     counterproductive.
>
>     (There are other places where the translation will necessarily
>     intrude; ideally, we want to keep those to reflective features,
>     those that cut across the language-level type system and the runtime
>     class system, such as class literals (Foo.class), instanceof,
>     casting, and reflection.)
>
>
>         I think keeping static fields per-class (in the sense of "the
>         class the user
>         wrote down in code", not "some random class artefact the runtime
>         happened to
>         emit") would be the most sensible and simple thing to do. No
>         explanation or
>         learning necessary, because everything works exactly like it has
>         the last 15
>         years in Java.
>
>
>

From vitalyd at gmail.com  Fri Aug  7 17:02:10 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Aug 2015 13:02:10 -0400
Subject: "Model 2" prototype status
In-Reply-To: <55C4E2B1.90507@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
	<55BF81F4.7010400@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
	<CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
	<55C4E2B1.90507@oracle.com>
Message-ID: <CAHjP37FxdjQKpnApXtFTtiLJ2zM8p9hwwHHmO_GYvdXdGXW3pQ@mail.gmail.com>

So in that case, considering the static T or Foo<T> members as belonging to
a concrete specialization is actually intuitive, at least to me.  What
would be weird is if the following was somehow handled differently:

class Foo<T> {
    static final T _t;
    static int _x;
}

where is _x and where is _t? How would I reflect over them at runtime?


On Fri, Aug 7, 2015 at 12:54 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Depends what you mean by out.  We are fully aware that this is a desirable
> and useful thing to be able to express, and intend to find a way to do so.
> But we don't think that complicating the semantics of statics is
> necessarily the right way to get there.  It has been suggested (thanks
> Peter) that borrowing the "object" notion from Scala would be a far better
> way to achieve this (and other things) than to change the semantics of
> static, and I'm inclined to agree.
>
> So the code below is probably "out" as written -- but that doesn't mean
> we've given up on solving the underlying problem.
>
>
>
>
> On 8/7/2015 12:46 PM, Vitaly Davidovich wrote:
>
>> I'd like to be able to express the following:
>>
>> class Foo<T> {
>>      static final T _t = ...;
>>      static final Foo<T> _ft = ...;
>> }
>>
>> I guess that's out?
>>
>> On Fri, Aug 7, 2015 at 12:37 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>>
>>     I don't see that there's any other sensible choice.  Asking users to
>>     reason about the partially-heterogeneous translation (where some
>>     instantiations share a class and some do not) in the context of an
>>     existing language feature like static fields would be silly -- and
>>     counterproductive.
>>
>>     (There are other places where the translation will necessarily
>>     intrude; ideally, we want to keep those to reflective features,
>>     those that cut across the language-level type system and the runtime
>>     class system, such as class literals (Foo.class), instanceof,
>>     casting, and reflection.)
>>
>>
>>         I think keeping static fields per-class (in the sense of "the
>>         class the user
>>         wrote down in code", not "some random class artefact the runtime
>>         happened to
>>         emit") would be the most sensible and simple thing to do. No
>>         explanation or
>>         learning necessary, because everything works exactly like it has
>>         the last 15
>>         years in Java.
>>
>>
>>
>>

From brian.goetz at oracle.com  Fri Aug  7 17:17:59 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 13:17:59 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37FxdjQKpnApXtFTtiLJ2zM8p9hwwHHmO_GYvdXdGXW3pQ@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<1438699645.4725.33.camel@sludev.com> <55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
	<CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
	<55C4E2B1.90507@oracle.com>
	<CAHjP37FxdjQKpnApXtFTtiLJ2zM8p9hwwHHmO_GYvdXdGXW3pQ@mail.gmail.com>
Message-ID: <55C4E847.7040201@oracle.com>

> So in that case, considering the static T or Foo<T> members as belonging
> to a concrete specialization is actually intuitive, at least to me.

We've had this discussion several times before, and still no one is 
buying this argument.

Coming from C# (or C++), which have different models for parametric 
polymorphism, it might make sense.  (Even if Java, it might have been 
"intuitive" if we had heterogeneously-translated generics from day one, 
but we didn't.)  In Java, statics have always been shared across 
instantiations (and they predate instantiations).  Having them shared 
across some instantiations (Foo<String> and Foo<Integer>) but not others 
(Foo<Integer> and Foo<int>) would be silly and definitely not intuitive.

Changing the current behavior (making them not shared across any 
instantiations) is completely off the table.  (Do I even have to say 
this?)

I understand what you want to express, and I agree its valuable that it 
be expressible.  But the path you're trying to sell is not the way to 
get us there.

From vitalyd at gmail.com  Fri Aug  7 17:31:47 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Aug 2015 13:31:47 -0400
Subject: "Model 2" prototype status
In-Reply-To: <55C4E847.7040201@oracle.com>
References: <55BBD188.8020406@oracle.com> <1438699645.4725.33.camel@sludev.com>
	<55C0E345.4050503@oracle.com>
	<1479191732.121280.1438715382639.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
	<CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
	<55C4E2B1.90507@oracle.com>
	<CAHjP37FxdjQKpnApXtFTtiLJ2zM8p9hwwHHmO_GYvdXdGXW3pQ@mail.gmail.com>
	<55C4E847.7040201@oracle.com>
Message-ID: <CAHjP37H7VVqpm+xai=zabjGaG=z0oa7hmXD393Wzs2PO-r6hJw@mail.gmail.com>

I'm saying it's intuitive (obviously subjective), not saying you need to do
it for java.

Having them shared across some instantiations (Foo<String> and
> Foo<Integer>) but not others (Foo<Integer> and Foo<int>) would be silly and
> definitely not intuitive.


Definitely, not proposing that type of inconsistency.

In Java, statics have always been shared across instantiations (and they
> predate instantiations)


Yup, java never had specialization or anything remotely close to reified
type info either.

But my question stands: given the scenario, where do _t and _x live?
Foo<String>._t vs Foo<int>._t and Foo<String>_x and Foo<int>._x? How would
it work with reflection?

On Fri, Aug 7, 2015 at 1:17 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> So in that case, considering the static T or Foo<T> members as belonging
>> to a concrete specialization is actually intuitive, at least to me.
>>
>
> We've had this discussion several times before, and still no one is buying
> this argument.
>
> Coming from C# (or C++), which have different models for parametric
> polymorphism, it might make sense.  (Even if Java, it might have been
> "intuitive" if we had heterogeneously-translated generics from day one, but
> we didn't.)  In Java, statics have always been shared across instantiations
> (and they predate instantiations).  Having them shared across some
> instantiations (Foo<String> and Foo<Integer>) but not others (Foo<Integer>
> and Foo<int>) would be silly and definitely not intuitive.
>
> Changing the current behavior (making them not shared across any
> instantiations) is completely off the table.  (Do I even have to say this?)
>
> I understand what you want to express, and I agree its valuable that it be
> expressible.  But the path you're trying to sell is not the way to get us
> there.
>

From brian.goetz at oracle.com  Fri Aug  7 18:29:14 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 14:29:14 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CAHjP37H7VVqpm+xai=zabjGaG=z0oa7hmXD393Wzs2PO-r6hJw@mail.gmail.com>
References: <55BBD188.8020406@oracle.com>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
	<CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
	<55C4E2B1.90507@oracle.com>
	<CAHjP37FxdjQKpnApXtFTtiLJ2zM8p9hwwHHmO_GYvdXdGXW3pQ@mail.gmail.com>
	<55C4E847.7040201@oracle.com>
	<CAHjP37H7VVqpm+xai=zabjGaG=z0oa7hmXD393Wzs2PO-r6hJw@mail.gmail.com>
Message-ID: <55C4F8FA.2030008@oracle.com>

> But my question stands: given the scenario, where do _t and _x live?
> Foo<String>._t vs Foo<int>._t and Foo<String>_x and Foo<int>._x? How
> would it work with reflection?

In the current prototype, they are shared across instantiations and are 
stored as static members on the erased class (Foo).  The compiler 
translates a static field access Foo<int>.x as "getfield Foo.x". 
Reflection on Foo.class will find these members; reflection on 
Foo<int>.class will not currently.  This is good enough for purposes of 
our current prototype.

We're investigating (that's code for "that's all I'm ready to say about 
it for now") some less ad-hoc ways of representing static members, as 
well as investigating how we're going to address the issue of 
per-instantiation values.  Stay tuned.


From forax at univ-mlv.fr  Fri Aug  7 18:12:45 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 07 Aug 2015 18:12:45 +0000
Subject: "Model 2" prototype status
In-Reply-To: <D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>
	<55BD3E97.3020206@oracle.com>
	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>
	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>
	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>
Message-ID: <EFC9852D-A79C-4ADA-A0A3-AEC595DA0B08@univ-mlv.fr>

Hi Gavin,
I think that Foo<val ?> is really interresting because it may solve the Foo<?> vs Foo<ref ?> issue.

Let suppose we have a construct which is able to do a switch on type (i think Pizza has something like that).

List<any> l = ...
switchOnType (l) {
  case List<val ?>:
    // here, l is typed as List<val ?> which is reified
    break;
  default: // here lies the dragon :)
     // here, l is typed as List<?>
}

with that trick, there is no need to denote List<ref ?> :)

cheers,
R?mi 



Le 3 ao?t 2015 15:43:18 CEST, Gavin Bierman <gavin.bierman at oracle.com> a ?crit :
>Hi Timo,
>
>> On 2 Aug 2015, at 21:55, Timo Kinnunen <timo.kinnunen at gmail.com>
>wrote:
>> 
>> Hi, 
>> 
>> Re: ?I don't care about the syntax but the one you propose doesn't
>help IMO.?
>> 
>> I have to agree. You really get a sense that there is no overall
>design behind this syntax backing it up. 
>> 
>> For example, my current source of confusion is whether A<any T> is to
>be interpreted as A<ref T | any T | null> or as A<ref T | any T |
>!(null)>. (A note on the syntax being used: the presence  or absence of
>the nulltype amongst the bounds is to be interpreted literally.)
>> 
>> Seeing ?Alternately, you can interpret "any T" as a union bound ("T
>extends Object | value")? suggests it?s the first interpretation that?s
>correct but then seeing ? Some operations that are allowed on ordinary
>tvars are not allowed on avars, such as assigning a T to an Object,
>assigning null to a T, etc.? suggests the correct interpretation should
>be the latter.
>> 
>> 
>> A properly designed syntax where such semantics can be expressed in a
>natural way will be helpful to have, one year from now. Would be much
>more helpful to have it right now though, IMHO?
>
>As I?m the semantics guy on the design team your request for semantics
>got my attention :-) (Plus I?d like to reassure you that there are
>hundreds of hours of thinking about the design so far; and many more to
>come!)
>
>Here?s a semantic take on what?s going on: A type is a set of values.
>In Java when declaring variables we are used to declaring their type,
>e.g. `Bar x`. A _sort_ is a set of types. Currently in Java when
>declaring type variables we do not declare their type/sort; it?s
>implicit, and is the set of all reference types. (Some languages do let
>you define the sorts of type variables, e.g. Haskell.) Of course we can
>constraint the set further with bounds, but morally type variables have
>a type/sort.
>
>In Valhalla we will be in the world where some type variables will
>range over all reference types, and some over other sorts. It?s this
>'other sorts' stuff that is new. In our experiments, we have identified
>three useful sorts: (i) `any` the sort containing all types, (ii) `ref`
>the sort containing all reference types (currently, the only sort
>denotable in Java), and (iii) `val` the sort containing all value types
>(currently the eight primitive types, but we are also experimenting
>with supporting user-defined value classes). We currently adopt a
>similar syntax for sort declarations as for type declarations, e.g.
>`ref X`, although other syntax choices could be taken from other
>languages, e.g. `X::ref`. We?re trying not to get too bogged down with
>syntax right now, but the idea should be clear.
>
>Placing a sort on a type variable in, for example, a class declaration
>can have consequences in the declaration body. If you declare a class
>`Pop<any T>` you are declaring it *for all* instantiations of T,
>including primitives. Hence in the body of declaration, you shouldn?t
>be able to assign null to an instance of the type variable, for
>example. It breaks the contract in the declaration. This is no
>different to Java 8, where we check in the body that we respect the
>bounds contract on type variables. 
>
>Given that wildcards are a form of existential type, corresponding to
>the three sorts are three forms of wildcards: (i) `Foo<any>` which
>denotes any type instantiation of `Foo`; (ii) `Foo<ref>` which denotes
>a reference type instantiation of `Foo` (this is currently written
>`Foo<?>` in Java); and (iii) `Foo<val>` which denotes a value type
>instantiation of `Foo`. Again, our syntax is preliminary; we could
>write these as `Foo<any ?>`, `Foo<ref ?>` and `Foo<val ?>`, for
>example.
>
>[BTW: Currently the prototype doesn?t support the `val` sort, but I
>wanted to add it to help you see what we?re up to.]
>
>I?m working on a more formal definition of the design and the
>translation strategy, which I can share with you when it?s ready, if
>you like. (It?ll look something like this:
>http://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf
><http://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf>)
>
>Hope this helps,
>Gavin


From forax at univ-mlv.fr  Fri Aug  7 18:01:34 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 07 Aug 2015 18:01:34 +0000
Subject: "Model 2" prototype implementation
In-Reply-To: <55C4D38B.4060503@oracle.com>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<55C4D38B.4060503@oracle.com>
Message-ID: <EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>

Hi Brian,
why do you need the interface Box$any and not use Object and send Box.class as a bootstrap argument to the indy call ?

R?mi 


Le 7 ao?t 2015 17:49:31 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>Great question.  We're working on a writeup of the translation details;
>
>we announced the prototype before the writeup was ready, because we 
>didn't want to keep early adopters from trying it out any further, but 
>there's a writeup coming.
>
>Here's a very brief taste (but you'll have to wait for the writeup, or 
>use javap on the output of javac, for more).  Imagine the function
>
>    R : Type -> Class
>
>which maps a compile-time type to a runtime class.  In Java 5 generics,
>
>for a class Foo<T>, the R mapping is very simple -- everything is
>erased:
>
>R(Foo<String>) = Foo
>R(Foo<?>) = Foo
>R(Foo) = Foo
>
>In Valhalla, for a class Foo<any T>, the mapping is more complex:
>
>Compatibility demands we adopt the above mappings:
>R(Foo<String>) = Foo
>R(Foo<ref>) = Foo
>R(Foo<raw>) = Foo
>
>And we get some new ones:
>R(Foo<int>) = Foo${0=I} *
>R(Foo<any>) = Foo$any **
>
>*Name mangling is temporary; something better is in the works.
>**Foo$any is a synthetic *interface* generated by javac, which can be 
>implemented by Foo<int> and Foo<String> alike (using boxing in the API 
>where necessary).
>
>Because Foo$any is an interface, it can't have fields.  So we lift the 
>fields of Foo to (possibly boxing) accessors on Foo$any (VM help is 
>needed for nonpublic members here), and we convert field accesses 
>(through receivers of type Foo<any> only!) to invocations of those 
>accessors.  (Field access through concretely-typed receivers 
>(Foo<String> or Foo<int>) are still translated with straight 
>getfield/putfield, so the boxing penalty is only paid by wildcard
>users.)
>
>Here's your example:
>
>     public static void main(String[] args) {
>         Box<int> box = new Box<int>(3);
>         Box<any> box_any = box;
>         System.out.println(box_any.get());
>         System.out.println(box_any.t);
>     }
>
>And the bytecode (which works as expected):
>
>public static void main(java.lang.String[]);
>     Code:
>        0: new           #2                  // class "Box${0=I}"
>        3: dup
>        4: iconst_3
>        5: invokespecial #3                  // Method 
>"Box${0=I}"."<init>":(I)V
>        8: astore_1
>        9: aload_1
>       10: astore_2
>       11: getstatic     #4                  // Field 
>java/lang/System.out:Ljava/io/PrintStream;
>       14: aload_2
>       15: invokedynamic #5,  0              // InvokeDynamic 
>#0:get:(LBox$$any;)Ljava/lang/Object;
>       20: invokevirtual #6                  // Method 
>java/io/PrintStream.println:(Ljava/lang/Object;)V
>       23: getstatic     #4                  // Field 
>java/lang/System.out:Ljava/io/PrintStream;
>       26: aload_2
>       27: invokedynamic #7,  0              // InvokeDynamic 
>#1:t$get:(LBox$$any;)Ljava/lang/Object;
>       32: invokevirtual #6                  // Method 
>java/io/PrintStream.println:(Ljava/lang/Object;)V
>       35: return
>
>BootstrapMethods:
>   0: #26 invokestatic 
>java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
>     Method arguments:
>       #27 invokeinterface Box$$any.get:()Ljava/lang/Object;
>   1: #26 invokestatic 
>java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
>     Method arguments:
>       #31 invokeinterface Box$$any.t$get:()Ljava/lang/Object;
>
>The invokedynamic at bci=15 and 27 invoke the get() and t$get() methods
>
>of the Foo$any interface.  We use invokedynamic instead of 
>invokeinterface because it allows us to do some boxing adaptations more
>
>easily than statically generating yet more bridge methods.  (The 
>VirtualAccess bootstrap simply does a MethodHandle.asType adaptation of
>
>the provided MH; in the current program, there is no difference in the 
>signatures so it's as if we did an invokeinterface of Box$$any.get() or
>
>.t$get() directly.)
>
>
>> I?m wondering how will the implementation work?
>> Specifically, in this example, which assumes a specialized |Box|
>class
>> defined here
>>
><web.archive.org/web/20150801070114/http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html#erasure-example-a-simple-box-class>:
>>
>> |Box<int> box = new Box<int>(4); Box<any> box_any = box; // what does
>> get() return? and how does it return it?
>> System.out.println(box_any.get()); // even more interesting, how does
>> this work: System.out.println(box_any.t /* assuming the box value is
>> visible */); |
>>
>> How do you translate the method calls and field accesses? Do they
>return
>> boxed values?
>>
>> Thanks,
>> Vlad
>>
>> PS: Shameless advertising ? I recently worked on a paper describing
>the
>> pitfalls I?ve encountered in miniboxing <http://scala-miniboxing.org>
>> when using erased views (and specialized views) and how to mitigate
>> them, which has been accepted for PPPJ 2015. In case you?re
>interested,
>> an earlier draft is available here
>> <http://infoscience.epfl.ch/record/208797?ln=en>.
>>
>> ?


From brian.goetz at oracle.com  Fri Aug  7 20:09:14 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 16:09:14 -0400
Subject: "Model 2" prototype implementation
In-Reply-To: <EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<55C4D38B.4060503@oracle.com>
	<EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
Message-ID: <55C5106A.1090907@oracle.com>

Sure, we could have chosen that.  But this is a more straightforward 
translation, and the simpler the translation is, the fewer dark corners 
there are.  For one thing, it means that instanceof/cast (and even more 
importantly, their reflective equivalents) *just work*.  It means that 
the subtyping is scrutable to the JIT and can feed information into 
optimizations.

Most dispatch on Foo<any> receivers can proceed without indy; the 
prototype happens to use it for dispatching all calls on Foo<any> 
receivers, but this is neither necessary nor optimal.



On 8/7/2015 2:01 PM, R?mi Forax wrote:
> Hi Brian,
> why do you need the interface Box$any and not use Object and send Box.class as a bootstrap argument to the indy call ?
>
> R?mi
>
>
> Le 7 ao?t 2015 17:49:31 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>> Great question.  We're working on a writeup of the translation details;
>>
>> we announced the prototype before the writeup was ready, because we
>> didn't want to keep early adopters from trying it out any further, but
>> there's a writeup coming.
>>
>> Here's a very brief taste (but you'll have to wait for the writeup, or
>> use javap on the output of javac, for more).  Imagine the function
>>
>>     R : Type -> Class
>>
>> which maps a compile-time type to a runtime class.  In Java 5 generics,
>>
>> for a class Foo<T>, the R mapping is very simple -- everything is
>> erased:
>>
>> R(Foo<String>) = Foo
>> R(Foo<?>) = Foo
>> R(Foo) = Foo
>>
>> In Valhalla, for a class Foo<any T>, the mapping is more complex:
>>
>> Compatibility demands we adopt the above mappings:
>> R(Foo<String>) = Foo
>> R(Foo<ref>) = Foo
>> R(Foo<raw>) = Foo
>>
>> And we get some new ones:
>> R(Foo<int>) = Foo${0=I} *
>> R(Foo<any>) = Foo$any **
>>
>> *Name mangling is temporary; something better is in the works.
>> **Foo$any is a synthetic *interface* generated by javac, which can be
>> implemented by Foo<int> and Foo<String> alike (using boxing in the API
>> where necessary).
>>
>> Because Foo$any is an interface, it can't have fields.  So we lift the
>> fields of Foo to (possibly boxing) accessors on Foo$any (VM help is
>> needed for nonpublic members here), and we convert field accesses
>> (through receivers of type Foo<any> only!) to invocations of those
>> accessors.  (Field access through concretely-typed receivers
>> (Foo<String> or Foo<int>) are still translated with straight
>> getfield/putfield, so the boxing penalty is only paid by wildcard
>> users.)
>>
>> Here's your example:
>>
>>      public static void main(String[] args) {
>>          Box<int> box = new Box<int>(3);
>>          Box<any> box_any = box;
>>          System.out.println(box_any.get());
>>          System.out.println(box_any.t);
>>      }
>>
>> And the bytecode (which works as expected):
>>
>> public static void main(java.lang.String[]);
>>      Code:
>>         0: new           #2                  // class "Box${0=I}"
>>         3: dup
>>         4: iconst_3
>>         5: invokespecial #3                  // Method
>> "Box${0=I}"."<init>":(I)V
>>         8: astore_1
>>         9: aload_1
>>        10: astore_2
>>        11: getstatic     #4                  // Field
>> java/lang/System.out:Ljava/io/PrintStream;
>>        14: aload_2
>>        15: invokedynamic #5,  0              // InvokeDynamic
>> #0:get:(LBox$$any;)Ljava/lang/Object;
>>        20: invokevirtual #6                  // Method
>> java/io/PrintStream.println:(Ljava/lang/Object;)V
>>        23: getstatic     #4                  // Field
>> java/lang/System.out:Ljava/io/PrintStream;
>>        26: aload_2
>>        27: invokedynamic #7,  0              // InvokeDynamic
>> #1:t$get:(LBox$$any;)Ljava/lang/Object;
>>        32: invokevirtual #6                  // Method
>> java/io/PrintStream.println:(Ljava/lang/Object;)V
>>        35: return
>>
>> BootstrapMethods:
>>    0: #26 invokestatic
>> java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
>>      Method arguments:
>>        #27 invokeinterface Box$$any.get:()Ljava/lang/Object;
>>    1: #26 invokestatic
>> java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
>>      Method arguments:
>>        #31 invokeinterface Box$$any.t$get:()Ljava/lang/Object;
>>
>> The invokedynamic at bci=15 and 27 invoke the get() and t$get() methods
>>
>> of the Foo$any interface.  We use invokedynamic instead of
>> invokeinterface because it allows us to do some boxing adaptations more
>>
>> easily than statically generating yet more bridge methods.  (The
>> VirtualAccess bootstrap simply does a MethodHandle.asType adaptation of
>>
>> the provided MH; in the current program, there is no difference in the
>> signatures so it's as if we did an invokeinterface of Box$$any.get() or
>>
>> .t$get() directly.)
>>
>>
>>> I?m wondering how will the implementation work?
>>> Specifically, in this example, which assumes a specialized |Box|
>> class
>>> defined here
>>>
>> <web.archive.org/web/20150801070114/http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html#erasure-example-a-simple-box-class>:
>>>
>>> |Box<int> box = new Box<int>(4); Box<any> box_any = box; // what does
>>> get() return? and how does it return it?
>>> System.out.println(box_any.get()); // even more interesting, how does
>>> this work: System.out.println(box_any.t /* assuming the box value is
>>> visible */); |
>>>
>>> How do you translate the method calls and field accesses? Do they
>> return
>>> boxed values?
>>>
>>> Thanks,
>>> Vlad
>>>
>>> PS: Shameless advertising ? I recently worked on a paper describing
>> the
>>> pitfalls I?ve encountered in miniboxing <http://scala-miniboxing.org>
>>> when using erased views (and specialized views) and how to mitigate
>>> them, which has been accepted for PPPJ 2015. In case you?re
>> interested,
>>> an earlier draft is available here
>>> <http://infoscience.epfl.ch/record/208797?ln=en>.
>>>
>>> ?
>

From mikeb01 at gmail.com  Fri Aug  7 20:41:33 2015
From: mikeb01 at gmail.com (Michael Barker)
Date: Sat, 8 Aug 2015 08:41:33 +1200
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <55C219DB.2090104@cs.oswego.edu>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
Message-ID: <CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>

Hi Doug,

Thank you for that info. I've just realised something but want to check my
reasoning.  The bounds check is effectively doing:

if (index >= entries.length)
    throw ArrayOutOfBoundsException();

Therefore even I use separate field to store the indexMask (entries.length
- 1) to avoid false sharing, the bounds check will effectively undo that
effort?

Mike.


On 6 August 2015 at 02:12, Doug Lea <dl at cs.oswego.edu> wrote:

> On 08/04/2015 05:25 PM, Michael Barker wrote:
>
> Thanks, I'll give that approach a try.  While it retains the padding on the
>> array entries it is lost for entries.length, so while it won't share a
>> cache line with the array entries it could share it with some other random
>> unknown thing.  I still have to run some more tests to see what the actual
>> costs end up being.  I suspect that I'll just suck up the cost of the
>> bounds checking,
>>
>
> That's what I've ended up doing in similar cases in java.util.concurrent.
> It does add variance depending on placement across runs of
> programs as well as within runs when GC moves things. But not
> much more variance than you see from other memory placement
> effects and JVM noise.
>
> It's worth reminding everyone that the need to do this
> stems from compiler limitations that in principle could
> be addressed someday. "Unsafe" access just means that
> the compiler cannot prove that an address is legal.
> It is frustrating that some cases that are obvious
> to their programmers cannot be proven -- as in an array
> that is only ever allocated with power-of-two size and
> accessed with masked indexing, but the allocation is outside
> the scope of compiler analysis.
>
> High-quality bounds-check optimizations generally require
> internal type systems and static analyses that are too
> expensive for JITs. (See for example the work done in the
> ahead-of-time X10 compiler.) But with the planned demise
> of Unsafe, perhaps some people interested in optimization
> will be more motivated to try to invent some more effective
> JIT-friendly approximations.
>
> -Doug
>
>
>

From vitalyd at gmail.com  Fri Aug  7 20:55:40 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Aug 2015 16:55:40 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
Message-ID: <CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>

>
> Therefore even I use separate field to store the indexMask (entries.length
> - 1) to avoid false sharing, the bounds check will effectively undo that
> effort?


Yes, anything that touches array.length can induce false sharing -- I
mentioned this earlier in this thread :) :

I think any approach that requires reading the length of an array, whether
> user or compiler inserted, is going to run afoul of possible false sharing;
> only approach #3 would work since the mask field could be isolated to its
> own cacheline.

The approach #3 you mentioned in the initial email could work *iff* JIT
started const propagating final fields and then seeing that your mask
guarantees an index < array.length *and* constant propagating the final
field holding the array and knowing its length > 0 (assuming we're talking
about a class with a final field array, which is true for typical
ringbuffers).  Right now, only Unsafe can help avoiding range checks and
false sharing.

On Fri, Aug 7, 2015 at 4:41 PM, Michael Barker <mikeb01 at gmail.com> wrote:

> Hi Doug,
>
> Thank you for that info. I've just realised something but want to check my
> reasoning.  The bounds check is effectively doing:
>
> if (index >= entries.length)
>     throw ArrayOutOfBoundsException();
>
> Therefore even I use separate field to store the indexMask (entries.length
> - 1) to avoid false sharing, the bounds check will effectively undo that
> effort?
>
> Mike.
>
>
> On 6 August 2015 at 02:12, Doug Lea <dl at cs.oswego.edu> wrote:
>
> > On 08/04/2015 05:25 PM, Michael Barker wrote:
> >
> > Thanks, I'll give that approach a try.  While it retains the padding on
> the
> >> array entries it is lost for entries.length, so while it won't share a
> >> cache line with the array entries it could share it with some other
> random
> >> unknown thing.  I still have to run some more tests to see what the
> actual
> >> costs end up being.  I suspect that I'll just suck up the cost of the
> >> bounds checking,
> >>
> >
> > That's what I've ended up doing in similar cases in java.util.concurrent.
> > It does add variance depending on placement across runs of
> > programs as well as within runs when GC moves things. But not
> > much more variance than you see from other memory placement
> > effects and JVM noise.
> >
> > It's worth reminding everyone that the need to do this
> > stems from compiler limitations that in principle could
> > be addressed someday. "Unsafe" access just means that
> > the compiler cannot prove that an address is legal.
> > It is frustrating that some cases that are obvious
> > to their programmers cannot be proven -- as in an array
> > that is only ever allocated with power-of-two size and
> > accessed with masked indexing, but the allocation is outside
> > the scope of compiler analysis.
> >
> > High-quality bounds-check optimizations generally require
> > internal type systems and static analyses that are too
> > expensive for JITs. (See for example the work done in the
> > ahead-of-time X10 compiler.) But with the planned demise
> > of Unsafe, perhaps some people interested in optimization
> > will be more motivated to try to invent some more effective
> > JIT-friendly approximations.
> >
> > -Doug
> >
> >
> >
>

From vitalyd at gmail.com  Fri Aug  7 21:01:56 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Aug 2015 17:01:56 -0400
Subject: "Model 2" prototype status
In-Reply-To: <55C4F8FA.2030008@oracle.com>
References: <55BBD188.8020406@oracle.com>
	<CAHjP37HQfCDjPRE7i8f2ciJqB3Wjqn5VtcgOxevCwu42d9bNgg@mail.gmail.com>
	<63000128.129618.1438771439039.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55c1f9a8.cb09b40a.2737f.5dcf@mx.google.com>
	<1651501836.141349.1438880195173.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37EnP6ugeO015uNXy+yFuzi4L6-+M8fTx7JnDo4bUkMhPA@mail.gmail.com>
	<1360364831.141670.1438885838575.JavaMail.open-xchange@srv005.service.ps-server.net>
	<CAHjP37GVUADgpDsvfd1rEB6HKf+kw2hKbuykbciVy4R_1umZrg@mail.gmail.com>
	<860594453.5077.1438964140175.JavaMail.open-xchange@srv005.service.ps-server.net>
	<55C4DED1.6000801@oracle.com>
	<CAHjP37HaP2yN0zYf3cHeSBCjoW9roQU4jzorhC=2-7zjTJEudw@mail.gmail.com>
	<55C4E2B1.90507@oracle.com>
	<CAHjP37FxdjQKpnApXtFTtiLJ2zM8p9hwwHHmO_GYvdXdGXW3pQ@mail.gmail.com>
	<55C4E847.7040201@oracle.com>
	<CAHjP37H7VVqpm+xai=zabjGaG=z0oa7hmXD393Wzs2PO-r6hJw@mail.gmail.com>
	<55C4F8FA.2030008@oracle.com>
Message-ID: <CAHjP37FaL4C7ETV_c6LMFHciCnx0MbvS0OH6_hOBBF-hT_ygLA@mail.gmail.com>

>
> In the current prototype, they are shared across instantiations and are
> stored as static members on the erased class (Foo).  The compiler
> translates a static field access Foo<int>.x as "getfield Foo.x". Reflection
> on Foo.class will find these members; reflection on Foo<int>.class will not
> currently.  This is good enough for purposes of our current prototype.


Where does it store the generic _t? And what is its type? Is it Object (or
erased upper bound) with a checkcast at the callsite?

On Fri, Aug 7, 2015 at 2:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> But my question stands: given the scenario, where do _t and _x live?
>> Foo<String>._t vs Foo<int>._t and Foo<String>_x and Foo<int>._x? How
>> would it work with reflection?
>>
>
> In the current prototype, they are shared across instantiations and are
> stored as static members on the erased class (Foo).  The compiler
> translates a static field access Foo<int>.x as "getfield Foo.x". Reflection
> on Foo.class will find these members; reflection on Foo<int>.class will not
> currently.  This is good enough for purposes of our current prototype.
>
> We're investigating (that's code for "that's all I'm ready to say about it
> for now") some less ad-hoc ways of representing static members, as well as
> investigating how we're going to address the issue of per-instantiation
> values.  Stay tuned.
>
>

From smarter3 at gmail.com  Fri Aug  7 21:03:33 2015
From: smarter3 at gmail.com (Guillaume Martres)
Date: Fri, 07 Aug 2015 23:03:33 +0200
Subject: "Model 2" prototype implementation
In-Reply-To: <55C5106A.1090907@oracle.com>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
	<55C5106A.1090907@oracle.com>
Message-ID: <2195385.ZKc82tVhMX@marvin>

On Friday 07 August 2015 16:09:14 Brian Goetz wrote:
> Most dispatch on Foo<any> receivers can proceed without indy; the
> prototype happens to use it for dispatching all calls on Foo<any>
> receivers, but this is neither necessary nor optimal.

Can you provide an example where it is necessary? I played a bit with the 
prototype but couldn't think of an example where it would.

From brian.goetz at oracle.com  Fri Aug  7 21:12:51 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 7 Aug 2015 17:12:51 -0400
Subject: "Model 2" prototype implementation
In-Reply-To: <2195385.ZKc82tVhMX@marvin>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
	<55C5106A.1090907@oracle.com> <2195385.ZKc82tVhMX@marvin>
Message-ID: <55C51F53.4050102@oracle.com>

Yep, that's because we haven't told the whole translation story in its 
full gory detail yet.  Stay tuned for the writeup.  (Spoiler: it has to 
do with types with multiple avars where some are wildcarded and others 
are not, like Map<int, any>.)

On 8/7/2015 5:03 PM, Guillaume Martres wrote:
> On Friday 07 August 2015 16:09:14 Brian Goetz wrote:
>> Most dispatch on Foo<any> receivers can proceed without indy; the
>> prototype happens to use it for dispatching all calls on Foo<any>
>> receivers, but this is neither necessary nor optimal.
>
> Can you provide an example where it is necessary? I played a bit with the
> prototype but couldn't think of an example where it would.
>

From brian.goetz at oracle.com  Fri Aug  7 22:32:57 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 07 Aug 2015 22:32:57 +0000
Subject: hg: valhalla/valhalla/jdk: Add adapters for Stream<int> -> IntStream
	and friends
Message-ID: <201508072232.t77MWvG8029637@aojmv0008.oracle.com>

Changeset: a42d2144de43
Author:    briangoetz
Date:      2015-08-07 18:32 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a42d2144de43

Add adapters for Stream<int> -> IntStream and friends

! src/java.base/share/classes/java/anyutil/OptionalDouble.java
! src/java.base/share/classes/java/anyutil/OptionalInt.java
! src/java.base/share/classes/java/anyutil/OptionalLong.java
! src/java.base/share/classes/java/anyutil/PrimitiveIterator.java
! src/java.base/share/classes/java/anyutil/Spliterator.java
! src/java.base/share/classes/java/anyutil/function/DoubleConsumer.java
! src/java.base/share/classes/java/anyutil/function/LongConsumer.java
! src/java.base/share/classes/java/anyutil/function/ObjDoubleConsumer.java
! src/java.base/share/classes/java/anyutil/function/ObjLongConsumer.java
! src/java.base/share/classes/java/anyutil/stream/DoubleStream.java
! src/java.base/share/classes/java/anyutil/stream/IntStream.java
! src/java.base/share/classes/java/anyutil/stream/LongStream.java
! src/java.base/share/classes/java/anyutil/stream/Pipeline.java


From peter.levart at gmail.com  Sat Aug  8 00:28:10 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 8 Aug 2015 02:28:10 +0200
Subject: VarAccessor - VarHandle alternative?
Message-ID: <55C54D1A.1010104@gmail.com>

Hi,

@PolymorphicSignature methods in VarHandle (combined with generics in 
FieldHandle) are a way to expose an API that does not explode in the 
number of different public classes for different primitive types. But 
aren't any-fied (specialized) generics doing just the same? I know: 
VarHandles are  proposed for JDK9 and any-fied generics aren't there yet.

Anyway, I tried to see if current state of any-fied generics allows me 
to build an API that is similar in footprint as VarHandle but fully 
compile-time type safe:

http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/vaccess/VarAccessor.java

With some tricks (type tokens and manual specialization by 
sub-classing), it can be done as a type-safe wrapper over Unsafe. This 
implementation is missing proper access checks. It's just a proof of 
concept.

While playing with this, I noticed a javac inconsistency. The following 
diamond:

public abstract class VarAccessor<T, any V> {

     private static final Map<Class<?>, BiFunction<Class<?>, String, 
VarAccessor<?, any>>> factories
         = new HashMap<>();

... does not work. I had to re-specify the full types in the HashMap 
constructor:

     private static final Map<Class<?>, BiFunction<Class<?>, String, 
VarAccessor<?, any>>> factories
         = new HashMap<Class<?>, BiFunction<Class<?>, String, 
VarAccessor<?, any>>>();


Regards, Peter


From chris at hazelcast.com  Sat Aug  8 06:52:21 2015
From: chris at hazelcast.com (Christoph Engelbert)
Date: Sat, 8 Aug 2015 08:52:21 +0200
Subject: VarAccessor - VarHandle alternative?
In-Reply-To: <55C54D1A.1010104@gmail.com>
References: <55C54D1A.1010104@gmail.com>
Message-ID: <E59DBA83-4B0A-400E-9694-C5B5302A8592@hazelcast.com>

Hey Peter,

That actually is a very interesting prototype and the implementation would be way easier than the current VarHandles. This kind of double dispatch on VarHandles (especially if you?re missing a specialization method in VarHandleGuards it kind of gets ugly).

I really like your idea!

Chris

> Am 08.08.2015 um 02:28 schrieb Peter Levart <peter.levart at gmail.com>:
> 
> Hi,
> 
> @PolymorphicSignature methods in VarHandle (combined with generics in FieldHandle) are a way to expose an API that does not explode in the number of different public classes for different primitive types. But aren't any-fied (specialized) generics doing just the same? I know: VarHandles are  proposed for JDK9 and any-fied generics aren't there yet.
> 
> Anyway, I tried to see if current state of any-fied generics allows me to build an API that is similar in footprint as VarHandle but fully compile-time type safe:
> 
> http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/vaccess/VarAccessor.java
> 
> With some tricks (type tokens and manual specialization by sub-classing), it can be done as a type-safe wrapper over Unsafe. This implementation is missing proper access checks. It's just a proof of concept.
> 
> While playing with this, I noticed a javac inconsistency. The following diamond:
> 
> public abstract class VarAccessor<T, any V> {
> 
>    private static final Map<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>> factories
>        = new HashMap<>();
> 
> ... does not work. I had to re-specify the full types in the HashMap constructor:
> 
>    private static final Map<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>> factories
>        = new HashMap<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>>();
> 
> 
> Regards, Peter
> 


From forax at univ-mlv.fr  Sat Aug  8 11:08:23 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 08 Aug 2015 11:08:23 +0000
Subject: VarAccessor - VarHandle alternative?
In-Reply-To: <E59DBA83-4B0A-400E-9694-C5B5302A8592@hazelcast.com>
References: <55C54D1A.1010104@gmail.com>
	<E59DBA83-4B0A-400E-9694-C5B5302A8592@hazelcast.com>
Message-ID: <6E7A927F-32DF-440E-9305-F14809D86C5B@univ-mlv.fr>

Yes,
that's a very good question !

I prefer your implemation too.

R?mi 


Le 8 ao?t 2015 08:52:21 CEST, Christoph Engelbert <chris at hazelcast.com> a ?crit :
>Hey Peter,
>
>That actually is a very interesting prototype and the implementation
>would be way easier than the current VarHandles. This kind of double
>dispatch on VarHandles (especially if you?re missing a specialization
>method in VarHandleGuards it kind of gets ugly).
>
>I really like your idea!
>
>Chris
>
>> Am 08.08.2015 um 02:28 schrieb Peter Levart <peter.levart at gmail.com>:
>> 
>> Hi,
>> 
>> @PolymorphicSignature methods in VarHandle (combined with generics in
>FieldHandle) are a way to expose an API that does not explode in the
>number of different public classes for different primitive types. But
>aren't any-fied (specialized) generics doing just the same? I know:
>VarHandles are  proposed for JDK9 and any-fied generics aren't there
>yet.
>> 
>> Anyway, I tried to see if current state of any-fied generics allows
>me to build an API that is similar in footprint as VarHandle but fully
>compile-time type safe:
>> 
>>
>http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/vaccess/VarAccessor.java
>> 
>> With some tricks (type tokens and manual specialization by
>sub-classing), it can be done as a type-safe wrapper over Unsafe. This
>implementation is missing proper access checks. It's just a proof of
>concept.
>> 
>> While playing with this, I noticed a javac inconsistency. The
>following diamond:
>> 
>> public abstract class VarAccessor<T, any V> {
>> 
>>    private static final Map<Class<?>, BiFunction<Class<?>, String,
>VarAccessor<?, any>>> factories
>>        = new HashMap<>();
>> 
>> ... does not work. I had to re-specify the full types in the HashMap
>constructor:
>> 
>>    private static final Map<Class<?>, BiFunction<Class<?>, String,
>VarAccessor<?, any>>> factories
>>        = new HashMap<Class<?>, BiFunction<Class<?>, String,
>VarAccessor<?, any>>>();
>> 
>> 
>> Regards, Peter
>> 


From brian.goetz at oracle.com  Sat Aug  8 16:05:30 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 8 Aug 2015 12:05:30 -0400
Subject: See you at JVMLS
Message-ID: <55C628CA.8070506@oracle.com>

I'll be doing a talk on the path from Model 1 to Model 2 (and a glimpse 
of Model 3) at JVMLS next week.  Hope to see some of you there.  Videos 
should go up on the Java YouTube channel fairly quickly after the 
conference.

In the meantime ... I'll just note that we've had 50+ messages on the 
various "Model 2" threads and none of them started with "I tried it out 
and..."

So a reminder ... the most valuable input the community can give in this 
process is to provide *actual experience reports*.  That's the main 
reason we make the significant investment in making the code and design 
sketches available early -- so that people can actually try it out, and 
help us see the holes that we might have missed.



From vlad.ureche at gmail.com  Sat Aug  8 17:15:03 2015
From: vlad.ureche at gmail.com (Vlad Ureche)
Date: Sat, 8 Aug 2015 19:15:03 +0200
Subject: "Model 2" prototype implementation
In-Reply-To: <55C51F53.4050102@oracle.com>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
	<55C5106A.1090907@oracle.com>
	<2195385.ZKc82tVhMX@marvin> <55C51F53.4050102@oracle.com>
Message-ID: <CAKBs1_pECAo-gYAx6gXToLsZ2fOm+e3s6YYsMJz9Wqzs8XarKg@mail.gmail.com>

Brian, thanks the explanation!

I?m very excited that the translation maps 1-to-1 to the Scala requirements
<https://speakerdeck.com/vladureche/valhalla-the-good-the-bad-and-the-ugly-scaladays-2015-san-francisco?slide=170>
(in the slide, the function R: Type -> Class is the right side, I called it
Reference).

There?s one thing I?d still like to have, if it doesn?t interact badly with
other features.
It?s in the same vein as T.default, only working inside classes/methods
with anyfied type parameters:

Object T#box(T t)
T T#unbox(Object t)v throws InvalidArgumentException

The boxing and unboxing operations could be patched in during the load-time
class specialization (they could be wired to identity in the erased class).
Would you be able to fit this in?

Thanks a lot and looking forward to the full write-up!
Vlad
PS: Normally I?d pick up the prototype and play around instead of asking
questions, but I?m writing my thesis, interviewing and preparing for
welcoming a baby, so I?ve got quite a few balls in the air right now.

On Fri, Aug 7, 2015 at 11:12 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

Yep, that's because we haven't told the whole translation story in its full
> gory detail yet.  Stay tuned for the writeup.  (Spoiler: it has to do with
> types with multiple avars where some are wildcarded and others are not,
> like Map<int, any>.)
>
>
> On 8/7/2015 5:03 PM, Guillaume Martres wrote:
>
>> On Friday 07 August 2015 16:09:14 Brian Goetz wrote:
>>
>>> Most dispatch on Foo<any> receivers can proceed without indy; the
>>> prototype happens to use it for dispatching all calls on Foo<any>
>>> receivers, but this is neither necessary nor optimal.
>>>
>>
>> Can you provide an example where it is necessary? I played a bit with the
>> prototype but couldn't think of an example where it would.
>>
>> ?

From brian.goetz at oracle.com  Sat Aug  8 17:24:28 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 8 Aug 2015 13:24:28 -0400
Subject: "Model 2" prototype implementation
In-Reply-To: <CAKBs1_pECAo-gYAx6gXToLsZ2fOm+e3s6YYsMJz9Wqzs8XarKg@mail.gmail.com>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
	<55C5106A.1090907@oracle.com> <2195385.ZKc82tVhMX@marvin>
	<55C51F53.4050102@oracle.com>
	<CAKBs1_pECAo-gYAx6gXToLsZ2fOm+e3s6YYsMJz9Wqzs8XarKg@mail.gmail.com>
Message-ID: <55C63B4C.9030103@oracle.com>

Yes, we definitely need some way of expressing that.  There's the 
obvious autoboxing conversions for concrete primitives / values, but it 
needs to be lifted to a general mechanism for conversion between any-T 
and Object (for reference types, this is a the identity conversion.)

(IIRC Peter Levart posted a really hacky way to do this a few months 
back, which is probably good enough to play with while we're working out 
the real story?)


On 8/8/2015 1:15 PM, Vlad Ureche wrote:
> Brian, thanks the explanation!
>
> I?m very excited that the translation maps 1-to-1 to the Scala
> requirements
> <https://speakerdeck.com/vladureche/valhalla-the-good-the-bad-and-the-ugly-scaladays-2015-san-francisco?slide=170>
> (in the slide, the function R: Type -> Class is the right side, I called
> it Reference).
>
> There?s one thing I?d still like to have, if it doesn?t interact badly
> with other features.
> It?s in the same vein as |T.default|, only working inside
> classes/methods with anyfied type parameters:
>
> |Object T#box(T t) T T#unbox(Object t)v throws InvalidArgumentException |
>
> The boxing and unboxing operations could be patched in during the
> load-time class specialization (they could be wired to identity in the
> erased class).
> Would you be able to fit this in?
>
> Thanks a lot and looking forward to the full write-up!
> Vlad
>
> PS: Normally I?d pick up the prototype and play around instead of asking
> questions, but I?m writing my thesis, interviewing and preparing for
> welcoming a baby, so I?ve got quite a few balls in the air right now.
>
> On Fri, Aug 7, 2015 at 11:12 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Yep, that's because we haven't told the whole translation story in
>     its full gory detail yet.  Stay tuned for the writeup.  (Spoiler: it
>     has to do with types with multiple avars where some are wildcarded
>     and others are not, like Map<int, any>.)
>
>
>     On 8/7/2015 5:03 PM, Guillaume Martres wrote:
>
>         On Friday 07 August 2015 16:09:14 Brian Goetz wrote:
>
>             Most dispatch on Foo<any> receivers can proceed without
>             indy; the
>             prototype happens to use it for dispatching all calls on
>             Foo<any>
>             receivers, but this is neither necessary nor optimal.
>
>
>         Can you provide an example where it is necessary? I played a bit
>         with the
>         prototype but couldn't think of an example where it would.
>
> ?

From forax at univ-mlv.fr  Sat Aug  8 19:50:23 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 08 Aug 2015 19:50:23 +0000
Subject: "Model 2" prototype implementation
In-Reply-To: <55C5106A.1090907@oracle.com>
References: <CAKBs1_pez3qb_1v9jGjH3etk9C1iLMBOsSho1zT-3xF6DWJQCA@mail.gmail.com>
	<55C4D38B.4060503@oracle.com>
	<EF74C86B-9334-467D-A00C-F0427C52293A@univ-mlv.fr>
	<55C5106A.1090907@oracle.com>
Message-ID: <B75F4A40-D249-4E12-8EC3-2D0A537FCE1C@univ-mlv.fr>



Le 7 ao?t 2015 22:09:14 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>Sure, we could have chosen that.  But this is a more straightforward 
>translation, and the simpler the translation is, the fewer dark corners
>
>there are.  

Adding synthetic interfaces to several user defined classes/interfaces is not something simple too.

> For one thing, it means that instanceof/cast

yes, may be. But i fail to see why List<any> need to be reified.

 (and even more
>
>importantly, their reflective equivalents) *just work*.  

I'm not sure that adding the syntax Foo<any>.class to Java is a good idea. Currently, it's a syntax error.
People will ask why Foo<any>.class is allowed but not Foo<?>.class

> It means that 
>the subtyping is scrutable to the JIT and can feed information into 
>optimizations.

JITs tend to use actual classes of the receiver instead of the declared type and Hotspot doesn't do CHA on interfaces.

>
>Most dispatch on Foo<any> receivers can proceed without indy; the 
>prototype happens to use it for dispatching all calls on Foo<any> 
>receivers, but this is neither necessary nor optimal.

Pick your poison, either you add an indy at callsite or you add bridges like methods (they aren't bridge methods because it's legal to have a user defined method that override them) to each classes and variants that are any-fied.

Indy can not be used too early when the VM is booting and is slow until being JITed. Bridge like methods mean more bloat to every anyfied classes for every variant (int/long/double/etc).

Also with bridge like methods, the boxing is done by the caller in bytecode (not different from a user requested boxing for the JIT POV) while with indy boxing is done at callsite (better for escape analysis) using asType() which doesn't require to preserve identity (better for partial escape analysis).

regards,
R?mi 

>
>
>
>On 8/7/2015 2:01 PM, R?mi Forax wrote:
>> Hi Brian,
>> why do you need the interface Box$any and not use Object and send
>Box.class as a bootstrap argument to the indy call ?
>>
>> R?mi
>>
>>
>> Le 7 ao?t 2015 17:49:31 CEST, Brian Goetz <brian.goetz at oracle.com> a
>?crit :
>>> Great question.  We're working on a writeup of the translation
>details;
>>>
>>> we announced the prototype before the writeup was ready, because we
>>> didn't want to keep early adopters from trying it out any further,
>but
>>> there's a writeup coming.
>>>
>>> Here's a very brief taste (but you'll have to wait for the writeup,
>or
>>> use javap on the output of javac, for more).  Imagine the function
>>>
>>>     R : Type -> Class
>>>
>>> which maps a compile-time type to a runtime class.  In Java 5
>generics,
>>>
>>> for a class Foo<T>, the R mapping is very simple -- everything is
>>> erased:
>>>
>>> R(Foo<String>) = Foo
>>> R(Foo<?>) = Foo
>>> R(Foo) = Foo
>>>
>>> In Valhalla, for a class Foo<any T>, the mapping is more complex:
>>>
>>> Compatibility demands we adopt the above mappings:
>>> R(Foo<String>) = Foo
>>> R(Foo<ref>) = Foo
>>> R(Foo<raw>) = Foo
>>>
>>> And we get some new ones:
>>> R(Foo<int>) = Foo${0=I} *
>>> R(Foo<any>) = Foo$any **
>>>
>>> *Name mangling is temporary; something better is in the works.
>>> **Foo$any is a synthetic *interface* generated by javac, which can
>be
>>> implemented by Foo<int> and Foo<String> alike (using boxing in the
>API
>>> where necessary).
>>>
>>> Because Foo$any is an interface, it can't have fields.  So we lift
>the
>>> fields of Foo to (possibly boxing) accessors on Foo$any (VM help is
>>> needed for nonpublic members here), and we convert field accesses
>>> (through receivers of type Foo<any> only!) to invocations of those
>>> accessors.  (Field access through concretely-typed receivers
>>> (Foo<String> or Foo<int>) are still translated with straight
>>> getfield/putfield, so the boxing penalty is only paid by wildcard
>>> users.)
>>>
>>> Here's your example:
>>>
>>>      public static void main(String[] args) {
>>>          Box<int> box = new Box<int>(3);
>>>          Box<any> box_any = box;
>>>          System.out.println(box_any.get());
>>>          System.out.println(box_any.t);
>>>      }
>>>
>>> And the bytecode (which works as expected):
>>>
>>> public static void main(java.lang.String[]);
>>>      Code:
>>>         0: new           #2                  // class "Box${0=I}"
>>>         3: dup
>>>         4: iconst_3
>>>         5: invokespecial #3                  // Method
>>> "Box${0=I}"."<init>":(I)V
>>>         8: astore_1
>>>         9: aload_1
>>>        10: astore_2
>>>        11: getstatic     #4                  // Field
>>> java/lang/System.out:Ljava/io/PrintStream;
>>>        14: aload_2
>>>        15: invokedynamic #5,  0              // InvokeDynamic
>>> #0:get:(LBox$$any;)Ljava/lang/Object;
>>>        20: invokevirtual #6                  // Method
>>> java/io/PrintStream.println:(Ljava/lang/Object;)V
>>>        23: getstatic     #4                  // Field
>>> java/lang/System.out:Ljava/io/PrintStream;
>>>        26: aload_2
>>>        27: invokedynamic #7,  0              // InvokeDynamic
>>> #1:t$get:(LBox$$any;)Ljava/lang/Object;
>>>        32: invokevirtual #6                  // Method
>>> java/io/PrintStream.println:(Ljava/lang/Object;)V
>>>        35: return
>>>
>>> BootstrapMethods:
>>>    0: #26 invokestatic
>>>
>java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
>>>      Method arguments:
>>>        #27 invokeinterface Box$$any.get:()Ljava/lang/Object;
>>>    1: #26 invokestatic
>>>
>java/lang/invoke/VirtualAccess.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
>>>      Method arguments:
>>>        #31 invokeinterface Box$$any.t$get:()Ljava/lang/Object;
>>>
>>> The invokedynamic at bci=15 and 27 invoke the get() and t$get()
>methods
>>>
>>> of the Foo$any interface.  We use invokedynamic instead of
>>> invokeinterface because it allows us to do some boxing adaptations
>more
>>>
>>> easily than statically generating yet more bridge methods.  (The
>>> VirtualAccess bootstrap simply does a MethodHandle.asType adaptation
>of
>>>
>>> the provided MH; in the current program, there is no difference in
>the
>>> signatures so it's as if we did an invokeinterface of Box$$any.get()
>or
>>>
>>> .t$get() directly.)
>>>
>>>
>>>> I?m wondering how will the implementation work?
>>>> Specifically, in this example, which assumes a specialized |Box|
>>> class
>>>> defined here
>>>>
>>>
><web.archive.org/web/20150801070114/http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html#erasure-example-a-simple-box-class>:
>>>>
>>>> |Box<int> box = new Box<int>(4); Box<any> box_any = box; // what
>does
>>>> get() return? and how does it return it?
>>>> System.out.println(box_any.get()); // even more interesting, how
>does
>>>> this work: System.out.println(box_any.t /* assuming the box value
>is
>>>> visible */); |
>>>>
>>>> How do you translate the method calls and field accesses? Do they
>>> return
>>>> boxed values?
>>>>
>>>> Thanks,
>>>> Vlad
>>>>
>>>> PS: Shameless advertising ? I recently worked on a paper describing
>>> the
>>>> pitfalls I?ve encountered in miniboxing
><http://scala-miniboxing.org>
>>>> when using erased views (and specialized views) and how to mitigate
>>>> them, which has been accepted for PPPJ 2015. In case you?re
>>> interested,
>>>> an earlier draft is available here
>>>> <http://infoscience.epfl.ch/record/208797?ln=en>.
>>>>
>>>> ?
>>


From timo.kinnunen at gmail.com  Sun Aug  9 01:30:20 2015
From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com)
Date: Sun, 9 Aug 2015 03:30:20 +0200
Subject: See you at JVMLS
In-Reply-To: <55C628CA.8070506@oracle.com>
References: <55C628CA.8070506@oracle.com>
Message-ID: <55c6ad33.a53ec20a.7e6be.ffffc95e@mx.google.com>

Hi, 

Inspired by these words, I tried it out for myself and ... it didn?t work. Specifically, and in the order of appearance, this didn?t work:

1. I didn?t find a link to instructions to try it out in my emails within the last 30 days. Eventually I picked a link in random to some change set in the Valhalla repository. There I navigated to its root and saw a change to README-builds.html 5 weeks ago. I took that as my intended destination. Action for improvement: it would be helpful to include a short reminder for where to go to get started when asking people try something out. Even if that?s been mentioned previously a little bit a repetition doesn?t cost anything.
2. The installation information for Cygwin is somewhat inaccurate as written. Specifically:
a. gawk.exe from Cygwin category Utils, contained in package awk: there is no package by that name, but the package gawk exists in category Base and is included by default. Action for improvement: this requirement seems to be outdated and should be removed.
b. file.exe from category Utils, contained in package file: package file can?t be found in the indicated category, but the package is found in category Base and is included by default. Action for improvement: this requirement seems to be outdated and should be removed.
3. The website for Mercurial cautions about the version of hg included in Cygwin without going into specifics. It is unclear from the README whether the build has been tested to work using the standalone Mercurial, the one in Cygwin or both. I took this to mean either one would be OK and picked hg from Cygwin. Action for improvement: mentioning both versions and anything special that should be considered when making the decision would let people make better decisions for their circumstances.
4. The website for Visual Studio doesn?t mention any Express edition. There is a Visual Studio 2015 Community edition, which is free and is intended for research, teaching, open-source and non-enterprise use. This appears to be the intended replacement for the 2013 Express edition, so I went with that. Action for improvement: the build should continue replacing old legacy components with their more modern counterparts.
5. Running bash ./configure results in configure: error: Could not find required tool for CMP error. Action for improvement: The package diffutils found in category Utils contains cmp.exe, which seems to be required by the build. This requirement should be listed in the table with the other requirements for Cygwin.

With the previous done and the variable VS120COMNTOOLS set to point to where VS140COMNTOOLS points, running bash ./configure now results in:

configure: Found Visual Studio installation at /cygdrive/d/build/Microsoft Visual Studio 14.0/ using VS120COMNTOOLS variable
configure: Found Microsoft Visual Studio 2013
configure: Rewriting VS_ENV_CMD to "/cygdrive/d/build/Microsoft Visual Studio 14.0/vc/bin/amd64/vcvars64.bat"
configure: Trying to extract Visual Studio environment variables
'D:/build/Microsoft' is not recognized as an internal or external command,
operable program or batch file.

As predicted by the README-builds.html, the configure script is handling the path "D:/build/Microsoft Visual Studio 14.0/vc/bin/amd64/vcvars64.bat" improperly, resulting in it getting cut off at the first space character. As could be guessed, the script doesn?t do very well after that.

And that?s why it didn?t work.




 
Sent from Mail for Windows 10



From: Brian Goetz
Sent: Saturday, August 8, 2015 18:06
To: valhalla-dev at openjdk.java.net
Subject: See you at JVMLS


I'll be doing a talk on the path from Model 1 to Model 2 (and a glimpse 
of Model 3) at JVMLS next week.  Hope to see some of you there.  Videos 
should go up on the Java YouTube channel fairly quickly after the 
conference.

In the meantime ... I'll just note that we've had 50+ messages on the 
various "Model 2" threads and none of them started with "I tried it out 
and..."

So a reminder ... the most valuable input the community can give in this 
process is to provide *actual experience reports*.  That's the main 
reason we make the significant investment in making the code and design 
sketches available early -- so that people can actually try it out, and 
help us see the holes that we might have missed.





From martijnverburg at gmail.com  Sun Aug  9 06:50:41 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 9 Aug 2015 07:50:41 +0100
Subject: See you at JVMLS
In-Reply-To: <55c6ad33.a53ec20a.7e6be.ffffc95e@mx.google.com>
References: <55C628CA.8070506@oracle.com>
	<55c6ad33.a53ec20a.7e6be.ffffc95e@mx.google.com>
Message-ID: <CAP7YuARvZup8F65J1LDGbtqU52KJ+CKSD57p5CSVFO7DtPV=sA@mail.gmail.com>

Hi Timo,

I'd report those issues to build-dev - building on windows can get a little
ropey at times.

When my Mac builds fail I just jump into a virtual box'd Ubuntu and build a
Linux version (almost always works).

Cheers,
Martijn

On Sunday, 9 August 2015, <timo.kinnunen at gmail.com> wrote:

> Hi,
>
> Inspired by these words, I tried it out for myself and ... it didn?t work.
> Specifically, and in the order of appearance, this didn?t work:
>
> 1. I didn?t find a link to instructions to try it out in my emails within
> the last 30 days. Eventually I picked a link in random to some change set
> in the Valhalla repository. There I navigated to its root and saw a change
> to README-builds.html 5 weeks ago. I took that as my intended destination.
> Action for improvement: it would be helpful to include a short reminder for
> where to go to get started when asking people try something out. Even if
> that?s been mentioned previously a little bit a repetition doesn?t cost
> anything.
> 2. The installation information for Cygwin is somewhat inaccurate as
> written. Specifically:
> a. gawk.exe from Cygwin category Utils, contained in package awk: there is
> no package by that name, but the package gawk exists in category Base and
> is included by default. Action for improvement: this requirement seems to
> be outdated and should be removed.
> b. file.exe from category Utils, contained in package file: package file
> can?t be found in the indicated category, but the package is found in
> category Base and is included by default. Action for improvement: this
> requirement seems to be outdated and should be removed.
> 3. The website for Mercurial cautions about the version of hg included in
> Cygwin without going into specifics. It is unclear from the README whether
> the build has been tested to work using the standalone Mercurial, the one
> in Cygwin or both. I took this to mean either one would be OK and picked hg
> from Cygwin. Action for improvement: mentioning both versions and anything
> special that should be considered when making the decision would let people
> make better decisions for their circumstances.
> 4. The website for Visual Studio doesn?t mention any Express edition.
> There is a Visual Studio 2015 Community edition, which is free and is
> intended for research, teaching, open-source and non-enterprise use. This
> appears to be the intended replacement for the 2013 Express edition, so I
> went with that. Action for improvement: the build should continue replacing
> old legacy components with their more modern counterparts.
> 5. Running bash ./configure results in configure: error: Could not find
> required tool for CMP error. Action for improvement: The package diffutils
> found in category Utils contains cmp.exe, which seems to be required by the
> build. This requirement should be listed in the table with the other
> requirements for Cygwin.
>
> With the previous done and the variable VS120COMNTOOLS set to point to
> where VS140COMNTOOLS points, running bash ./configure now results in:
>
> configure: Found Visual Studio installation at /cygdrive/d/build/Microsoft
> Visual Studio 14.0/ using VS120COMNTOOLS variable
> configure: Found Microsoft Visual Studio 2013
> configure: Rewriting VS_ENV_CMD to "/cygdrive/d/build/Microsoft Visual
> Studio 14.0/vc/bin/amd64/vcvars64.bat"
> configure: Trying to extract Visual Studio environment variables
> 'D:/build/Microsoft' is not recognized as an internal or external command,
> operable program or batch file.
>
> As predicted by the README-builds.html, the configure script is handling
> the path "D:/build/Microsoft Visual Studio 14.0/vc/bin/amd64/vcvars64.bat"
> improperly, resulting in it getting cut off at the first space character.
> As could be guessed, the script doesn?t do very well after that.
>
> And that?s why it didn?t work.
>
>
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Brian Goetz
> Sent: Saturday, August 8, 2015 18:06
> To: valhalla-dev at openjdk.java.net <javascript:;>
> Subject: See you at JVMLS
>
>
> I'll be doing a talk on the path from Model 1 to Model 2 (and a glimpse
> of Model 3) at JVMLS next week.  Hope to see some of you there.  Videos
> should go up on the Java YouTube channel fairly quickly after the
> conference.
>
> In the meantime ... I'll just note that we've had 50+ messages on the
> various "Model 2" threads and none of them started with "I tried it out
> and..."
>
> So a reminder ... the most valuable input the community can give in this
> process is to provide *actual experience reports*.  That's the main
> reason we make the significant investment in making the code and design
> sketches available early -- so that people can actually try it out, and
> help us see the holes that we might have missed.
>
>
>
>
>

-- 
Cheers, Martijn (Sent from Gmail Mobile)

From richard.warburton at gmail.com  Sun Aug  9 09:09:41 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Sun, 9 Aug 2015 10:09:41 +0100
Subject: See you at JVMLS
In-Reply-To: <55c6ad33.a53ec20a.7e6be.ffffc95e@mx.google.com>
References: <55C628CA.8070506@oracle.com>
	<55c6ad33.a53ec20a.7e6be.ffffc95e@mx.google.com>
Message-ID: <CAMaYbvJQg1umSujz99zfVGMZLzWtHwPJ9C9QOpwfpQsnU0uU3g@mail.gmail.com>

Hi Timo,

Inspired by these words, I tried it out for myself and ... it didn?t work.
> Specifically, and in the order of appearance, this didn?t work:


1. I didn?t find a link to instructions to try it out in my emails within
> the last 30 days. Eventually I picked a link in random to some change set
> in the Valhalla repository. There I navigated to its root and saw a change
> to README-builds.html 5 weeks ago. I took that as my intended destination.
> Action for improvement: it would be helpful to include a short reminder for
> where to go to get started when asking people try something out. Even if
> that?s been mentioned previously a little bit a repetition doesn?t cost
> anything.
>

You'll waste less time if you just use a linux VM to be honest. Even once
you get it building on windows, incremental compilation won't work.

The actual source code links and instructions for linux are available in
the section entitled "Source Code and Building Valhalla" on
http://openjdk.java.net/projects/valhalla/

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>

From kervin at sludev.com  Sun Aug  9 23:33:24 2015
From: kervin at sludev.com (Kervin Pierre)
Date: Sun, 9 Aug 2015 23:33:24 +0000
Subject: See you at JVMLS
In-Reply-To: <CAP7YuARvZup8F65J1LDGbtqU52KJ+CKSD57p5CSVFO7DtPV=sA@mail.gmail.com>
References: <55C628CA.8070506@oracle.com>
	<55c6ad33.a53ec20a.7e6be.ffffc95e@mx.google.com>
	<CAP7YuARvZup8F65J1LDGbtqU52KJ+CKSD57p5CSVFO7DtPV=sA@mail.gmail.com>
Message-ID: <1439163202.6071.11.camel@sludev.com>

Agreed.  Maybe also give Boot2Docker [ http://boot2docker.io/ ] a try?

Best regards,
Kervin

On Sun, 2015-08-09 at 07:50 +0100, Martijn Verburg wrote:
> Hi Timo,
> 
> I'd report those issues to build-dev - building on windows can get a little
> ropey at times.
> 
> When my Mac builds fail I just jump into a virtual box'd Ubuntu and build a
> Linux version (almost always works).
> 
> Cheers,
> Martijn
> 
> On Sunday, 9 August 2015, <timo.kinnunen at gmail.com> wrote:
> 
> > Hi,
> >
> > Inspired by these words, I tried it out for myself and ... it didn?t work.
> > Specifically, and in the order of appearance, this didn?t work:
> >
> > 1. I didn?t find a link to instructions to try it out in my emails within
> > the last 30 days. Eventually I picked a link in random to some change set
> > in the Valhalla repository. There I navigated to its root and saw a change
> > to README-builds.html 5 weeks ago. I took that as my intended destination.
> > Action for improvement: it would be helpful to include a short reminder for
> > where to go to get started when asking people try something out. Even if
> > that?s been mentioned previously a little bit a repetition doesn?t cost
> > anything.
> > 2. The installation information for Cygwin is somewhat inaccurate as
> > written. Specifically:
> > a. gawk.exe from Cygwin category Utils, contained in package awk: there is
> > no package by that name, but the package gawk exists in category Base and
> > is included by default. Action for improvement: this requirement seems to
> > be outdated and should be removed.
> > b. file.exe from category Utils, contained in package file: package file
> > can?t be found in the indicated category, but the package is found in
> > category Base and is included by default. Action for improvement: this
> > requirement seems to be outdated and should be removed.
> > 3. The website for Mercurial cautions about the version of hg included in
> > Cygwin without going into specifics. It is unclear from the README whether
> > the build has been tested to work using the standalone Mercurial, the one
> > in Cygwin or both. I took this to mean either one would be OK and picked hg
> > from Cygwin. Action for improvement: mentioning both versions and anything
> > special that should be considered when making the decision would let people
> > make better decisions for their circumstances.
> > 4. The website for Visual Studio doesn?t mention any Express edition.
> > There is a Visual Studio 2015 Community edition, which is free and is
> > intended for research, teaching, open-source and non-enterprise use. This
> > appears to be the intended replacement for the 2013 Express edition, so I
> > went with that. Action for improvement: the build should continue replacing
> > old legacy components with their more modern counterparts.
> > 5. Running bash ./configure results in configure: error: Could not find
> > required tool for CMP error. Action for improvement: The package diffutils
> > found in category Utils contains cmp.exe, which seems to be required by the
> > build. This requirement should be listed in the table with the other
> > requirements for Cygwin.
> >
> > With the previous done and the variable VS120COMNTOOLS set to point to
> > where VS140COMNTOOLS points, running bash ./configure now results in:
> >
> > configure: Found Visual Studio installation at /cygdrive/d/build/Microsoft
> > Visual Studio 14.0/ using VS120COMNTOOLS variable
> > configure: Found Microsoft Visual Studio 2013
> > configure: Rewriting VS_ENV_CMD to "/cygdrive/d/build/Microsoft Visual
> > Studio 14.0/vc/bin/amd64/vcvars64.bat"
> > configure: Trying to extract Visual Studio environment variables
> > 'D:/build/Microsoft' is not recognized as an internal or external command,
> > operable program or batch file.
> >
> > As predicted by the README-builds.html, the configure script is handling
> > the path "D:/build/Microsoft Visual Studio 14.0/vc/bin/amd64/vcvars64.bat"
> > improperly, resulting in it getting cut off at the first space character.
> > As could be guessed, the script doesn?t do very well after that.
> >
> > And that?s why it didn?t work.
> >
> >
> >
> >
> >
> > Sent from Mail for Windows 10
> >
> >
> >
> > From: Brian Goetz
> > Sent: Saturday, August 8, 2015 18:06
> > To: valhalla-dev at openjdk.java.net <javascript:;>
> > Subject: See you at JVMLS
> >
> >
> > I'll be doing a talk on the path from Model 1 to Model 2 (and a glimpse
> > of Model 3) at JVMLS next week.  Hope to see some of you there.  Videos
> > should go up on the Java YouTube channel fairly quickly after the
> > conference.
> >
> > In the meantime ... I'll just note that we've had 50+ messages on the
> > various "Model 2" threads and none of them started with "I tried it out
> > and..."
> >
> > So a reminder ... the most valuable input the community can give in this
> > process is to provide *actual experience reports*.  That's the main
> > reason we make the significant investment in making the code and design
> > sketches available early -- so that people can actually try it out, and
> > help us see the holes that we might have missed.
> >
> >
> >
> >
> >
> 


From maurizio.cimadamore at oracle.com  Mon Aug 10 12:01:38 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 10 Aug 2015 12:01:38 +0000
Subject: hg: valhalla/valhalla/langtools: Misc fixes:
Message-ID: <201508101201.t7AC1chJ011940@aojmv0008.oracle.com>

Changeset: c8a45eddf171
Author:    mcimadamore
Date:      2015-08-10 13:01 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c8a45eddf171

Misc fixes:
* spurious inference error when inferred type contains any wildcards
* members inherithed from non-virtual classes/interfaces do not need virtual accessors

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
+ test/tools/javac/valhalla/typespec/Inference09.java
+ test/tools/javac/valhalla/typespec/Wildcards10.java


From maurizio.cimadamore at oracle.com  Mon Aug 10 12:02:21 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 10 Aug 2015 13:02:21 +0100
Subject: VarAccessor - VarHandle alternative?
In-Reply-To: <55C54D1A.1010104@gmail.com>
References: <55C54D1A.1010104@gmail.com>
Message-ID: <55C892CD.1060906@oracle.com>

Hi Peter,
thanks for the report; this should have been fixed now.

Maurizio

On 08/08/15 01:28, Peter Levart wrote:
> While playing with this, I noticed a javac inconsistency. The 
> following diamond:
>
> public abstract class VarAccessor<T, any V> {
>
>     private static final Map<Class<?>, BiFunction<Class<?>, String, 
> VarAccessor<?, any>>> factories
>         = new HashMap<>();
>
> ... does not work. I had to re-specify the full types in the HashMap 
> constructor:
>
>     private static final Map<Class<?>, BiFunction<Class<?>, String, 
> VarAccessor<?, any>>> factories
>         = new HashMap<Class<?>, BiFunction<Class<?>, String, 
> VarAccessor<?, any>>>();
>
>
> Regards, Peter 


From peter.levart at gmail.com  Tue Aug 11 20:34:14 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 11 Aug 2015 22:34:14 +0200
Subject: java.lang.Class literals
Message-ID: <55CA5C46.8070907@gmail.com>

Hi,

Given:

class Single<any T> {}

We can express j.l.Class literals representing specialized classes with:

Single<boolean>.class
Single<byte>.class
Syngle<char>.class
...

We can express the Class representing common interface implemented by 
specialized and raw classes with:

Single<any>.class

And we can express the Class representing raw class itself with:

Single.class

The following are not possible:

error: illegal generic type for class literal
         test(Single<?>.class);

error: illegal generic type for class literal
         test(Single<Object>.class);

But that's OK, since they all represent the same j.l.Class as 
Single.class and we don't need many ways to express the same thing.



But let us take the following:

class Double<any T, any U> {}

Class literals for full specializations (where both type parameters are 
value types) are possible to express:

Double<byte, byte>.class);
Double<byte, char>.class);
Double<char, byte>.class);
Double<char, char>.class);
...
...

So is the common interface implemented by all classes (specialized and raw):

Double<any, any>.class

What's interesting is that there is no special run-time representation 
for a type inbetween:

Double<byte, byte>  <:  Double<any, byte>  <: Double<any, any>

Double<any, byte> gets "erased" to Double<any, any>.class, but we can 
still write Double<any, byte>.class which just represents an alias for 
Double<any, any>.class.

There's also the raw class representation which is used for 
all-reference type var instantitations:

Double.class

But I couldn't find a way to express a Class literal representing class 
used at runtime for the following type, for example:

Double<Object, int>

error: illegal generic type for class literal
         test(Double<?, any>.class);


It's easy to work-around this limitation:

     static class Double<any T, any U> {
         static <any T, any U> Class<?> clazz() {
             return Double<T, U>.class;
         }
     }

...and use:

Double.<Object, byte>clazz()  instead of  Double<?, byte>.class


So I wonder if that Class literal limitations could be lifted and allow 
the following:

     Double<?, int>.class
     Double<int, ?>.class
     ...

And, for consistency, also the following:

     Double<?, ?>.class (which would be another way to say Double.class)


What do you think?

Regards, Peter


From brian.goetz at oracle.com  Wed Aug 12 04:30:14 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 11 Aug 2015 21:30:14 -0700
Subject: java.lang.Class literals
In-Reply-To: <55CA5C46.8070907@gmail.com>
References: <55CA5C46.8070907@gmail.com>
Message-ID: <C6205E98-37A4-4EE4-B1A8-09D1944B8F06@oracle.com>

> We can express j.l.Class literals representing specialized classes with:

? all true, and this set of behaviors is reasonable, but bear in mind that what is supported here and not supported here is mostly accidental ? this is currently a very rough edge and a lot more thought is needed before you should infer anything about intent from the behavior...

> But let us take the following:
> 
> class Double<any T, any U> {}

? which goes at least doubly true for multiple type variables.  

> 
> What's interesting is that there is no special run-time representation for a type inbetween:
> 
> Double<byte, byte>  <:  Double<any, byte>  <: Double<any, any>
> 
> Double<any, byte> gets "erased" to Double<any, any>.class, but we can still write Double<any, byte>.class which just represents an alias for Double<any, any>.class.

That?s correct, though we?ve not yet explained our strategy here on the translation story for multiple type variables (writeup in progress) nor are we convinced that the current compiler behavior is exactly in line with our intentions here.  More work needed.  

> So I wonder if that Class literal limitations could be lifted and allow the following:
> 
>   Double<?, int>.class
>   Double<int, ?>.class

Not unreasonable.  We have yet to really start working on the connection to reflection, though.  Of course, we have some ideas, but right now the compiler basically does ?something? but probably best to not read too much into why it does that particular something rather than something else.  

> And, for consistency, also the following:

Rather than reasoning from ?consistency with what else works now?, better to look for a credible rule that tells us what should work and what should not :)  

> What do you think?

All seems reasonable.  But dealing with the reflective story requires some other things to settle out first, and then we plan to revisit the whole reflection story.



From boaznahum at gmail.com  Thu Aug 13 09:04:06 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 13 Aug 2015 09:04:06 +0000
Subject: Current state of valhalla
In-Reply-To: <55CA5C46.8070907@gmail.com>
References: <55CA5C46.8070907@gmail.com>
Message-ID: <CAB_DFWZEDpE2e+7FLHnEi7xVW4-ZR57nxyNYzZ_82wf0NpPDwg@mail.gmail.com>

Hi

I'm building valhalla on daily basis, and trying to follow this email list
to understand what can I expected from the current implementation.

I wonder there is other way, for examples - examples in the repository, or
other useful links ?

Thx
Boaz

From maurizio.cimadamore at oracle.com  Thu Aug 13 09:46:09 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 13 Aug 2015 10:46:09 +0100
Subject: Current state of valhalla
In-Reply-To: <CAB_DFWZEDpE2e+7FLHnEi7xVW4-ZR57nxyNYzZ_82wf0NpPDwg@mail.gmail.com>
References: <55CA5C46.8070907@gmail.com>
	<CAB_DFWZEDpE2e+7FLHnEi7xVW4-ZR57nxyNYzZ_82wf0NpPDwg@mail.gmail.com>
Message-ID: <55CC6761.1010403@oracle.com>

Hi Boaz,
probably the most extensive examples using anyfied code will be found in 
the experimental 'java.anyutil' package that we are using to play with 
the stream API anyfication:

hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/src/java.base/share/classes/java/anyutil

Other examples can be found in the runtime specializer tests:

hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/test/valhalla

As well as in compiler tests:

http://hg.openjdk.java.net/valhalla/valhalla/langtools/file/tip/test/tools/javac/valhalla/typespec

For other relevant, and more high level info, also check out the 
following documents:

http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html 
[overview of specialization - this is rather old an we're working on a 
new version]
http://cr.openjdk.java.net/~mcimadamore/specializationAttrs-v0.3.html 
[overview of extra attributes generated by the specializing compiler]
http://cr.openjdk.java.net/~jrose/values/values.html [overview of value 
types support - most of the stuff here is not implemented as we speak]

Maurizio

On 13/08/15 10:04, Boaz Nahum wrote:
> Hi
>
> I'm building valhalla on daily basis, and trying to follow this email list
> to understand what can I expected from the current implementation.
>
> I wonder there is other way, for examples - examples in the repository, or
> other useful links ?
>
> Thx
> Boaz


From boaznahum at gmail.com  Fri Aug 14 10:07:02 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 10:07:02 +0000
Subject: Fwd: cygwin too old ?
In-Reply-To: <55CDB0A4.3000104@oracle.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>
	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>
	<55CDB0A4.3000104@oracle.com>
Message-ID: <CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>

Many thanks

Whom should I asked to do this sync?

Boaz


On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <ingemar.aberg at oracle.com>
wrote:

> Hi Boaz,
>
> Your problem looks like JDK-8079087
> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been fixed
> in jdk9/dev. Maybe the Valhalla project needs to sync.
>
> /ingo
>
> On 2015-08-14 10:41, Boaz Nahum wrote:
> > Can any one assist ? Please ?
> >
> > ---------- Forwarded message ---------
> > From: Boaz Nahum <boaznahum at gmail.com>
> > Date: Sun, Aug 9, 2015 at 9:12 PM
> > Subject: cygwin too old ?
> > To: build-dev-request at openjdk.java.net <
> build-dev-request at openjdk.java.net>
> >
> >
> > I got this error message when trying to build
> > http://hg.openjdk.java.net/valhalla/valhalla
> >
> > configure: Your cygwin is too old. You are running 2.2.0(0.289/5/3), but
> at
> > least cygwin 1.7 is required. Please upgrade.
> >
> > Please help !
> >
> > Boaz
>
>

From maurizio.cimadamore at oracle.com  Fri Aug 14 10:18:25 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 14 Aug 2015 10:18:25 +0000
Subject: hg: valhalla/valhalla: 8079087: Add support for Cygwin 2.0
Message-ID: <201508141018.t7EAIPu8012859@aojmv0008.oracle.com>

Changeset: 21ba2e4d36ca
Author:    mcimadamore
Date:      2015-08-14 11:18 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/21ba2e4d36ca

8079087: Add support for Cygwin 2.0
Reviewed-by: tbell

! common/autoconf/basics_windows.m4
! common/autoconf/generated-configure.sh


From maurizio.cimadamore at oracle.com  Fri Aug 14 10:18:56 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Aug 2015 11:18:56 +0100
Subject: Fwd: cygwin too old ?
In-Reply-To: <CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>	<55CDB0A4.3000104@oracle.com>
	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
Message-ID: <55CDC090.3000303@oracle.com>

I've pushed a temp workaround for this; let me know if it works for you.

Maurizio

On 14/08/15 11:07, Boaz Nahum wrote:
> Many thanks
>
> Whom should I asked to do this sync?
>
> Boaz
>
>
> On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <ingemar.aberg at oracle.com>
> wrote:
>
>> Hi Boaz,
>>
>> Your problem looks like JDK-8079087
>> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been fixed
>> in jdk9/dev. Maybe the Valhalla project needs to sync.
>>
>> /ingo
>>
>> On 2015-08-14 10:41, Boaz Nahum wrote:
>>> Can any one assist ? Please ?
>>>
>>> ---------- Forwarded message ---------
>>> From: Boaz Nahum <boaznahum at gmail.com>
>>> Date: Sun, Aug 9, 2015 at 9:12 PM
>>> Subject: cygwin too old ?
>>> To: build-dev-request at openjdk.java.net <
>> build-dev-request at openjdk.java.net>
>>>
>>> I got this error message when trying to build
>>> http://hg.openjdk.java.net/valhalla/valhalla
>>>
>>> configure: Your cygwin is too old. You are running 2.2.0(0.289/5/3), but
>> at
>>> least cygwin 1.7 is required. Please upgrade.
>>>
>>> Please help !
>>>
>>> Boaz
>>


From boaznahum at gmail.com  Fri Aug 14 10:19:23 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 10:19:23 +0000
Subject: Current state of valhalla
In-Reply-To: <55CC6761.1010403@oracle.com>
References: <55CA5C46.8070907@gmail.com>
	<CAB_DFWZEDpE2e+7FLHnEi7xVW4-ZR57nxyNYzZ_82wf0NpPDwg@mail.gmail.com>
	<55CC6761.1010403@oracle.com>
Message-ID: <CAB_DFWa0rskmDQ-E2k_zKY8qYsR-c0Vji=8-tFPumWF5x4Pq8w@mail.gmail.com>

awesome !!! I Never was so excited about JDK version

Thx !!!!

On Thu, Aug 13, 2015 at 12:46 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Boaz,
> probably the most extensive examples using anyfied code will be found in
> the experimental 'java.anyutil' package that we are using to play with
> the stream API anyfication:
>
>
> hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/src/java.base/share/classes/java/anyutil
>
> Other examples can be found in the runtime specializer tests:
>
> hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/test/valhalla
>
> As well as in compiler tests:
>
>
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/file/tip/test/tools/javac/valhalla/typespec
>
> For other relevant, and more high level info, also check out the
> following documents:
>
> http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html
> [overview of specialization - this is rather old an we're working on a
> new version]
> http://cr.openjdk.java.net/~mcimadamore/specializationAttrs-v0.3.html
> [overview of extra attributes generated by the specializing compiler]
> http://cr.openjdk.java.net/~jrose/values/values.html [overview of value
> types support - most of the stuff here is not implemented as we speak]
>
> Maurizio
>
> On 13/08/15 10:04, Boaz Nahum wrote:
> > Hi
> >
> > I'm building valhalla on daily basis, and trying to follow this email
> list
> > to understand what can I expected from the current implementation.
> >
> > I wonder there is other way, for examples - examples in the repository,
> or
> > other useful links ?
> >
> > Thx
> > Boaz
>
>

From boaznahum at gmail.com  Fri Aug 14 10:53:10 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 10:53:10 +0000
Subject: Fwd: cygwin too old ?
In-Reply-To: <55CDC090.3000303@oracle.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>
	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>
	<55CDB0A4.3000104@oracle.com>
	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
	<55CDC090.3000303@oracle.com>
Message-ID: <CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>

Yes, it works.
Thx
Boaz


On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I've pushed a temp workaround for this; let me know if it works for you.
>
> Maurizio
>
> On 14/08/15 11:07, Boaz Nahum wrote:
> > Many thanks
> >
> > Whom should I asked to do this sync?
> >
> > Boaz
> >
> >
> > On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <ingemar.aberg at oracle.com
> >
> > wrote:
> >
> >> Hi Boaz,
> >>
> >> Your problem looks like JDK-8079087
> >> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been
> fixed
> >> in jdk9/dev. Maybe the Valhalla project needs to sync.
> >>
> >> /ingo
> >>
> >> On 2015-08-14 10:41, Boaz Nahum wrote:
> >>> Can any one assist ? Please ?
> >>>
> >>> ---------- Forwarded message ---------
> >>> From: Boaz Nahum <boaznahum at gmail.com>
> >>> Date: Sun, Aug 9, 2015 at 9:12 PM
> >>> Subject: cygwin too old ?
> >>> To: build-dev-request at openjdk.java.net <
> >> build-dev-request at openjdk.java.net>
> >>>
> >>> I got this error message when trying to build
> >>> http://hg.openjdk.java.net/valhalla/valhalla
> >>>
> >>> configure: Your cygwin is too old. You are running 2.2.0(0.289/5/3),
> but
> >> at
> >>> least cygwin 1.7 is required. Please upgrade.
> >>>
> >>> Please help !
> >>>
> >>> Boaz
> >>
>
>

From boaznahum at gmail.com  Fri Aug 14 11:43:53 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 11:43:53 +0000
Subject: Fwd: cygwin too old ?
In-Reply-To: <CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>
	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>
	<55CDB0A4.3000104@oracle.com>
	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
	<55CDC090.3000303@oracle.com>
	<CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>
Message-ID: <CAB_DFWa33+77oFKfUksaB5Z-Xx9N6KNYsQRs9i41=ck_Xo1d+g@mail.gmail.com>

Thx now I have valhalla on my win 10  :)

One more little sync request

src/share/vm/classfile/systemDictionary.cpp

contains error:

-  return (strstr(str, str_to_find));

Should be

+  return (strstr(str, str_to_find)) != NULL;

It was fixed on jdk9dev

Can I asked for this sync too ?

Boaz

On Fri, Aug 14, 2015 at 1:53 PM Boaz Nahum <boaznahum at gmail.com> wrote:

> Yes, it works.
> Thx
> Boaz
>
>
> On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> I've pushed a temp workaround for this; let me know if it works for you.
>>
>> Maurizio
>>
>> On 14/08/15 11:07, Boaz Nahum wrote:
>> > Many thanks
>> >
>> > Whom should I asked to do this sync?
>> >
>> > Boaz
>> >
>> >
>> > On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <
>> ingemar.aberg at oracle.com>
>> > wrote:
>> >
>> >> Hi Boaz,
>> >>
>> >> Your problem looks like JDK-8079087
>> >> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been
>> fixed
>> >> in jdk9/dev. Maybe the Valhalla project needs to sync.
>> >>
>> >> /ingo
>> >>
>> >> On 2015-08-14 10:41, Boaz Nahum wrote:
>> >>> Can any one assist ? Please ?
>> >>>
>> >>> ---------- Forwarded message ---------
>> >>> From: Boaz Nahum <boaznahum at gmail.com>
>> >>> Date: Sun, Aug 9, 2015 at 9:12 PM
>> >>> Subject: cygwin too old ?
>> >>> To: build-dev-request at openjdk.java.net <
>> >> build-dev-request at openjdk.java.net>
>> >>>
>> >>> I got this error message when trying to build
>> >>> http://hg.openjdk.java.net/valhalla/valhalla
>> >>>
>> >>> configure: Your cygwin is too old. You are running 2.2.0(0.289/5/3),
>> but
>> >> at
>> >>> least cygwin 1.7 is required. Please upgrade.
>> >>>
>> >>> Please help !
>> >>>
>> >>> Boaz
>> >>
>>
>>

From maurizio.cimadamore at oracle.com  Fri Aug 14 12:08:29 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Aug 2015 13:08:29 +0100
Subject: Fwd: cygwin too old ?
In-Reply-To: <CAB_DFWa33+77oFKfUksaB5Z-Xx9N6KNYsQRs9i41=ck_Xo1d+g@mail.gmail.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>	<55CDB0A4.3000104@oracle.com>	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>	<55CDC090.3000303@oracle.com>	<CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>
	<CAB_DFWa33+77oFKfUksaB5Z-Xx9N6KNYsQRs9i41=ck_Xo1d+g@mail.gmail.com>
Message-ID: <55CDDA3D.9080508@oracle.com>

Is this only an error with Windows build?

Maurizio

On 14/08/15 12:43, Boaz Nahum wrote:
> Thx now I have valhalla on my win 10  :)
>
> One more little sync request
>
> src/share/vm/classfile/systemDictionary.cpp
>
> contains error:
>
> -  return (strstr(str, str_to_find));
>
> Should be
>
> +  return (strstr(str, str_to_find)) != NULL;
>
> It was fixed on jdk9dev
>
> Can I asked for this sync too ?
>
> Boaz
>
> On Fri, Aug 14, 2015 at 1:53 PM Boaz Nahum <boaznahum at gmail.com> wrote:
>
>> Yes, it works.
>> Thx
>> Boaz
>>
>>
>> On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>>> I've pushed a temp workaround for this; let me know if it works for you.
>>>
>>> Maurizio
>>>
>>> On 14/08/15 11:07, Boaz Nahum wrote:
>>>> Many thanks
>>>>
>>>> Whom should I asked to do this sync?
>>>>
>>>> Boaz
>>>>
>>>>
>>>> On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <
>>> ingemar.aberg at oracle.com>
>>>> wrote:
>>>>
>>>>> Hi Boaz,
>>>>>
>>>>> Your problem looks like JDK-8079087
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been
>>> fixed
>>>>> in jdk9/dev. Maybe the Valhalla project needs to sync.
>>>>>
>>>>> /ingo
>>>>>
>>>>> On 2015-08-14 10:41, Boaz Nahum wrote:
>>>>>> Can any one assist ? Please ?
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: Boaz Nahum <boaznahum at gmail.com>
>>>>>> Date: Sun, Aug 9, 2015 at 9:12 PM
>>>>>> Subject: cygwin too old ?
>>>>>> To: build-dev-request at openjdk.java.net <
>>>>> build-dev-request at openjdk.java.net>
>>>>>> I got this error message when trying to build
>>>>>> http://hg.openjdk.java.net/valhalla/valhalla
>>>>>>
>>>>>> configure: Your cygwin is too old. You are running 2.2.0(0.289/5/3),
>>> but
>>>>> at
>>>>>> least cygwin 1.7 is required. Please upgrade.
>>>>>>
>>>>>> Please help !
>>>>>>
>>>>>> Boaz
>>>


From boaznahum at gmail.com  Fri Aug 14 12:27:55 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 12:27:55 +0000
Subject: Fwd: cygwin too old ?
In-Reply-To: <55CDDA3D.9080508@oracle.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>
	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>
	<55CDB0A4.3000104@oracle.com>
	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
	<55CDC090.3000303@oracle.com>
	<CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>
	<CAB_DFWa33+77oFKfUksaB5Z-Xx9N6KNYsQRs9i41=ck_Xo1d+g@mail.gmail.com>
	<55CDDA3D.9080508@oracle.com>
Message-ID: <CAB_DFWY0Xki=kYSr2B5CNcw_GFHAv592ST-ZXJpTh69YNMgq8g@mail.gmail.com>

YES !!!


On Fri, Aug 14, 2015 at 3:08 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Is this only an error with Windows build?
>
> Maurizio
>
> On 14/08/15 12:43, Boaz Nahum wrote:
> > Thx now I have valhalla on my win 10  :)
> >
> > One more little sync request
> >
> > src/share/vm/classfile/systemDictionary.cpp
> >
> > contains error:
> >
> > -  return (strstr(str, str_to_find));
> >
> > Should be
> >
> > +  return (strstr(str, str_to_find)) != NULL;
> >
> > It was fixed on jdk9dev
> >
> > Can I asked for this sync too ?
> >
> > Boaz
> >
> > On Fri, Aug 14, 2015 at 1:53 PM Boaz Nahum <boaznahum at gmail.com> wrote:
> >
> >> Yes, it works.
> >> Thx
> >> Boaz
> >>
> >>
> >> On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore <
> >> maurizio.cimadamore at oracle.com> wrote:
> >>
> >>> I've pushed a temp workaround for this; let me know if it works for
> you.
> >>>
> >>> Maurizio
> >>>
> >>> On 14/08/15 11:07, Boaz Nahum wrote:
> >>>> Many thanks
> >>>>
> >>>> Whom should I asked to do this sync?
> >>>>
> >>>> Boaz
> >>>>
> >>>>
> >>>> On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <
> >>> ingemar.aberg at oracle.com>
> >>>> wrote:
> >>>>
> >>>>> Hi Boaz,
> >>>>>
> >>>>> Your problem looks like JDK-8079087
> >>>>> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been
> >>> fixed
> >>>>> in jdk9/dev. Maybe the Valhalla project needs to sync.
> >>>>>
> >>>>> /ingo
> >>>>>
> >>>>> On 2015-08-14 10:41, Boaz Nahum wrote:
> >>>>>> Can any one assist ? Please ?
> >>>>>>
> >>>>>> ---------- Forwarded message ---------
> >>>>>> From: Boaz Nahum <boaznahum at gmail.com>
> >>>>>> Date: Sun, Aug 9, 2015 at 9:12 PM
> >>>>>> Subject: cygwin too old ?
> >>>>>> To: build-dev-request at openjdk.java.net <
> >>>>> build-dev-request at openjdk.java.net>
> >>>>>> I got this error message when trying to build
> >>>>>> http://hg.openjdk.java.net/valhalla/valhalla
> >>>>>>
> >>>>>> configure: Your cygwin is too old. You are running 2.2.0(0.289/5/3),
> >>> but
> >>>>> at
> >>>>>> least cygwin 1.7 is required. Please upgrade.
> >>>>>>
> >>>>>> Please help !
> >>>>>>
> >>>>>> Boaz
> >>>
>
>

From maurizio.cimadamore at oracle.com  Fri Aug 14 12:52:05 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 14 Aug 2015 12:52:05 +0000
Subject: hg: valhalla/valhalla/hotspot: Fix: small tweak to make hotspot code
	Windows-build friendly
Message-ID: <201508141252.t7ECq5xk003954@aojmv0008.oracle.com>

Changeset: db0e0957dc6b
Author:    mcimadamore
Date:      2015-08-14 13:51 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/db0e0957dc6b

Fix: small tweak to make hotspot code Windows-build friendly
Contributed-by: boaznahum at gmail.com

! src/share/vm/classfile/systemDictionary.cpp


From maurizio.cimadamore at oracle.com  Fri Aug 14 12:52:13 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Aug 2015 13:52:13 +0100
Subject: Fwd: cygwin too old ?
In-Reply-To: <CAB_DFWY0Xki=kYSr2B5CNcw_GFHAv592ST-ZXJpTh69YNMgq8g@mail.gmail.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>
	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>
	<55CDB0A4.3000104@oracle.com>
	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
	<55CDC090.3000303@oracle.com>
	<CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>
	<CAB_DFWa33+77oFKfUksaB5Z-Xx9N6KNYsQRs9i41=ck_Xo1d+g@mail.gmail.com>
	<55CDDA3D.9080508@oracle.com>
	<CAB_DFWY0Xki=kYSr2B5CNcw_GFHAv592ST-ZXJpTh69YNMgq8g@mail.gmail.com>
Message-ID: <55CDE47D.60206@oracle.com>

Ok - got it; the original comment that this was fixed in 9 got me off 
track; the code in question is new in Valhalla repo, so there's no JDK 9 
equivalent for it. It's just a bug/glitch in the following hostpot patch:

http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/419818b23594

Fixed now.

Maurizio


On 14/08/15 13:27, Boaz Nahum wrote:
> YES !!!
>
>
> On Fri, Aug 14, 2015 at 3:08 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Is this only an error with Windows build?
>
>     Maurizio
>
>     On 14/08/15 12:43, Boaz Nahum wrote:
>     > Thx now I have valhalla on my win 10  :)
>     >
>     > One more little sync request
>     >
>     > src/share/vm/classfile/systemDictionary.cpp
>     >
>     > contains error:
>     >
>     > -  return (strstr(str, str_to_find));
>     >
>     > Should be
>     >
>     > +  return (strstr(str, str_to_find)) != NULL;
>     >
>     > It was fixed on jdk9dev
>     >
>     > Can I asked for this sync too ?
>     >
>     > Boaz
>     >
>     > On Fri, Aug 14, 2015 at 1:53 PM Boaz Nahum <boaznahum at gmail.com
>     <mailto:boaznahum at gmail.com>> wrote:
>     >
>     >> Yes, it works.
>     >> Thx
>     >> Boaz
>     >>
>     >>
>     >> On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore <
>     >> maurizio.cimadamore at oracle.com
>     <mailto:maurizio.cimadamore at oracle.com>> wrote:
>     >>
>     >>> I've pushed a temp workaround for this; let me know if it
>     works for you.
>     >>>
>     >>> Maurizio
>     >>>
>     >>> On 14/08/15 11:07, Boaz Nahum wrote:
>     >>>> Many thanks
>     >>>>
>     >>>> Whom should I asked to do this sync?
>     >>>>
>     >>>> Boaz
>     >>>>
>     >>>>
>     >>>> On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <
>     >>> ingemar.aberg at oracle.com <mailto:ingemar.aberg at oracle.com>>
>     >>>> wrote:
>     >>>>
>     >>>>> Hi Boaz,
>     >>>>>
>     >>>>> Your problem looks like JDK-8079087
>     >>>>> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which
>     has been
>     >>> fixed
>     >>>>> in jdk9/dev. Maybe the Valhalla project needs to sync.
>     >>>>>
>     >>>>> /ingo
>     >>>>>
>     >>>>> On 2015-08-14 10:41, Boaz Nahum wrote:
>     >>>>>> Can any one assist ? Please ?
>     >>>>>>
>     >>>>>> ---------- Forwarded message ---------
>     >>>>>> From: Boaz Nahum <boaznahum at gmail.com
>     <mailto:boaznahum at gmail.com>>
>     >>>>>> Date: Sun, Aug 9, 2015 at 9:12 PM
>     >>>>>> Subject: cygwin too old ?
>     >>>>>> To: build-dev-request at openjdk.java.net
>     <mailto:build-dev-request at openjdk.java.net> <
>     >>>>> build-dev-request at openjdk.java.net
>     <mailto:build-dev-request at openjdk.java.net>>
>     >>>>>> I got this error message when trying to build
>     >>>>>> http://hg.openjdk.java.net/valhalla/valhalla
>     >>>>>>
>     >>>>>> configure: Your cygwin is too old. You are running
>     2.2.0(0.289/5/3),
>     >>> but
>     >>>>> at
>     >>>>>> least cygwin 1.7 is required. Please upgrade.
>     >>>>>>
>     >>>>>> Please help !
>     >>>>>>
>     >>>>>> Boaz
>     >>>
>


From boaznahum at gmail.com  Fri Aug 14 13:30:43 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 13:30:43 +0000
Subject: Fwd: cygwin too old ?
In-Reply-To: <55CDE47D.60206@oracle.com>
References: <CAB_DFWZ4=rj8mpMmKy5V=cM0GJQ3Rw7Pg0gHJ7Poo9LjXNVhkA@mail.gmail.com>
	<CAB_DFWZin=nZAzdzyrGWegt_ee7KKRT9yxrRLHPVU2evBy7V0g@mail.gmail.com>
	<55CDB0A4.3000104@oracle.com>
	<CAB_DFWZrXTxrWqrsMBUFuMNj06TZsANq2kFAWXHH=RUQXdm=ng@mail.gmail.com>
	<55CDC090.3000303@oracle.com>
	<CAB_DFWZmvAKAMFC59_vwnJ8ib5FugtG=dbEo5-4RcZPrw8zNgQ@mail.gmail.com>
	<CAB_DFWa33+77oFKfUksaB5Z-Xx9N6KNYsQRs9i41=ck_Xo1d+g@mail.gmail.com>
	<55CDDA3D.9080508@oracle.com>
	<CAB_DFWY0Xki=kYSr2B5CNcw_GFHAv592ST-ZXJpTh69YNMgq8g@mail.gmail.com>
	<55CDE47D.60206@oracle.com>
Message-ID: <CAB_DFWYd76jkTrd8h8-v0UjwOkS0ji82gvOoB5tAbGVoN4r+8g@mail.gmail.com>

Now it works

Thx
boaz


On Fri, Aug 14, 2015 at 3:52 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Ok - got it; the original comment that this was fixed in 9 got me off
> track; the code in question is new in Valhalla repo, so there's no JDK 9
> equivalent for it. It's just a bug/glitch in the following hostpot patch:
>
> http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/419818b23594
>
> Fixed now.
>
>
> Maurizio
>
>
>
> On 14/08/15 13:27, Boaz Nahum wrote:
>
> YES !!!
>
>
> On Fri, Aug 14, 2015 at 3:08 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> Is this only an error with Windows build?
>>
>> Maurizio
>>
>> On 14/08/15 12:43, Boaz Nahum wrote:
>> > Thx now I have valhalla on my win 10  :)
>> >
>> > One more little sync request
>> >
>> > src/share/vm/classfile/systemDictionary.cpp
>> >
>> > contains error:
>> >
>> > -  return (strstr(str, str_to_find));
>> >
>> > Should be
>> >
>> > +  return (strstr(str, str_to_find)) != NULL;
>> >
>> > It was fixed on jdk9dev
>> >
>> > Can I asked for this sync too ?
>> >
>> > Boaz
>> >
>> > On Fri, Aug 14, 2015 at 1:53 PM Boaz Nahum <boaznahum at gmail.com> wrote:
>> >
>> >> Yes, it works.
>> >> Thx
>> >> Boaz
>> >>
>> >>
>> >> On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore <
>> >> maurizio.cimadamore at oracle.com> wrote:
>> >>
>> >>> I've pushed a temp workaround for this; let me know if it works for
>> you.
>> >>>
>> >>> Maurizio
>> >>>
>> >>> On 14/08/15 11:07, Boaz Nahum wrote:
>> >>>> Many thanks
>> >>>>
>> >>>> Whom should I asked to do this sync?
>> >>>>
>> >>>> Boaz
>> >>>>
>> >>>>
>> >>>> On Fri, Aug 14, 2015 at 12:12 PM Ingemar ?berg <
>> >>> ingemar.aberg at oracle.com>
>> >>>> wrote:
>> >>>>
>> >>>>> Hi Boaz,
>> >>>>>
>> >>>>> Your problem looks like JDK-8079087
>> >>>>> <https://bugs.openjdk.java.net/browse/JDK-8079087>, which has been
>> >>> fixed
>> >>>>> in jdk9/dev. Maybe the Valhalla project needs to sync.
>> >>>>>
>> >>>>> /ingo
>> >>>>>
>> >>>>> On 2015-08-14 10:41, Boaz Nahum wrote:
>> >>>>>> Can any one assist ? Please ?
>> >>>>>>
>> >>>>>> ---------- Forwarded message ---------
>> >>>>>> From: Boaz Nahum <boaznahum at gmail.com>
>> >>>>>> Date: Sun, Aug 9, 2015 at 9:12 PM
>> >>>>>> Subject: cygwin too old ?
>> >>>>>> To: build-dev-request at openjdk.java.net <
>> >>>>> build-dev-request at openjdk.java.net>
>> >>>>>> I got this error message when trying to build
>> >>>>>> http://hg.openjdk.java.net/valhalla/valhalla
>> >>>>>>
>> >>>>>> configure: Your cygwin is too old. You are running
>> 2.2.0(0.289/5/3),
>> >>> but
>> >>>>> at
>> >>>>>> least cygwin 1.7 is required. Please upgrade.
>> >>>>>>
>> >>>>>> Please help !
>> >>>>>>
>> >>>>>> Boaz
>> >>>
>>
>>
>

From boaznahum at gmail.com  Fri Aug 14 14:15:53 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 14 Aug 2015 14:15:53 +0000
Subject: How to implement Box.equals
Message-ID: <CAB_DFWaK9vfGDH_ejMTwvn29jCUraVPkS9x40ah+w5J8jcousg@mail.gmail.com>

How can one implement something simple as Box.eqauls

I tried:

public class PSupport {
    static boolean equals(boolean x, boolean y) { return x == y;}
    static boolean equals(int x, byte y) { return x == y;}
    static boolean equals(char x, char y) { return x == y;}
    static boolean equals(short x, short y) { return x == y;}
    static boolean equals(int x, int y) { return x == y;}
    static boolean equals(long x, long y) { return x == y;}
    static boolean equals(float x, float y) { return x == y;}
    static boolean equals(double x, double y) { return x == y;}
    static boolean equals(Object x, Object y) { return Objects.equals(x, y); }

}


public class Box<any X> {

    private final X x;

    public Box(X x) { this.x = x;}

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Box<X> box = (Box<X>) o;

        return PSupport.equals(x, box.x);
    }

}

But it doesn't accept PSupport.equals(x, box.x);

Thx

Boaz

From maurizio.cimadamore at oracle.com  Fri Aug 14 14:33:13 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Aug 2015 15:33:13 +0100
Subject: How to implement Box.equals
In-Reply-To: <CAB_DFWaK9vfGDH_ejMTwvn29jCUraVPkS9x40ah+w5J8jcousg@mail.gmail.com>
References: <CAB_DFWaK9vfGDH_ejMTwvn29jCUraVPkS9x40ah+w5J8jcousg@mail.gmail.com>
Message-ID: <55CDFC29.4070301@oracle.com>

Peter Levart posted quite an interesting approach while back:

http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/javany-webrev.01/src/java.base/share/classes/java/util/Any.java.html

Maurizio

On 14/08/15 15:15, Boaz Nahum wrote:
> How can one implement something simple as Box.eqauls
>
> I tried:
>
> public class PSupport {
>      static boolean equals(boolean x, boolean y) { return x == y;}
>      static boolean equals(int x, byte y) { return x == y;}
>      static boolean equals(char x, char y) { return x == y;}
>      static boolean equals(short x, short y) { return x == y;}
>      static boolean equals(int x, int y) { return x == y;}
>      static boolean equals(long x, long y) { return x == y;}
>      static boolean equals(float x, float y) { return x == y;}
>      static boolean equals(double x, double y) { return x == y;}
>      static boolean equals(Object x, Object y) { return Objects.equals(x, y); }
>
> }
>
>
> public class Box<any X> {
>
>      private final X x;
>
>      public Box(X x) { this.x = x;}
>
>      @Override
>      public boolean equals(Object o) {
>          if (this == o) return true;
>          if (o == null || getClass() != o.getClass()) return false;
>
>          Box<X> box = (Box<X>) o;
>
>          return PSupport.equals(x, box.x);
>      }
>
> }
>
> But it doesn't accept PSupport.equals(x, box.x);
>
> Thx
>
> Boaz


From paul.sandoz at oracle.com  Sun Aug 16 05:41:34 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 16 Aug 2015 07:41:34 +0200
Subject: VarAccessor - VarHandle alternative?
In-Reply-To: <55C54D1A.1010104@gmail.com>
References: <55C54D1A.1010104@gmail.com>
Message-ID: <481362EF-53D9-4C56-919C-0C143632C19A@oracle.com>

HI Peter,

Sorry for the late reply, got sucked into JVMLS, and travel back, and now holiday (back on 27th).

Thanks for experimenting with this. We pulled back from the Field/Array-specific handle experiments in a previous revision of the variable handle JEP because we knew we could do similar kinds of wrapping as you have shown. The idea being a VarHandle could be wrapped in a class that encapsulates the specific shape associated with a variable kind, and VarHandle becomes the primary place where unsafe access is corralled.

Paul.

On 8 Aug 2015, at 02:28, Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
> 
> @PolymorphicSignature methods in VarHandle (combined with generics in FieldHandle) are a way to expose an API that does not explode in the number of different public classes for different primitive types. But aren't any-fied (specialized) generics doing just the same? I know: VarHandles are  proposed for JDK9 and any-fied generics aren't there yet.
> 
> Anyway, I tried to see if current state of any-fied generics allows me to build an API that is similar in footprint as VarHandle but fully compile-time type safe:
> 
> http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/vaccess/VarAccessor.java
> 
> With some tricks (type tokens and manual specialization by sub-classing), it can be done as a type-safe wrapper over Unsafe. This implementation is missing proper access checks. It's just a proof of concept.
> 
> While playing with this, I noticed a javac inconsistency. The following diamond:
> 
> public abstract class VarAccessor<T, any V> {
> 
>    private static final Map<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>> factories
>        = new HashMap<>();
> 
> ... does not work. I had to re-specify the full types in the HashMap constructor:
> 
>    private static final Map<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>> factories
>        = new HashMap<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>>();
> 
> 
> Regards, Peter
> 


From forax at univ-mlv.fr  Sun Aug 16 08:41:27 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 16 Aug 2015 08:41:27 +0000
Subject: VarAccessor - VarHandle alternative?
In-Reply-To: <481362EF-53D9-4C56-919C-0C143632C19A@oracle.com>
References: <55C54D1A.1010104@gmail.com>
	<481362EF-53D9-4C56-919C-0C143632C19A@oracle.com>
Message-ID: <83D6A761-DD6A-41F1-8D49-D17F940E016C@univ-mlv.fr>

Hi Paul,
the thing is that if VarHandle is wrapped, you control the callsites so you don't need the VarHandle methods to use polymorphic signatures anymore.

cheers,
R?mi 

Le 16 ao?t 2015 07:41:34 CEST, Paul Sandoz <paul.sandoz at oracle.com> a ?crit :
>HI Peter,
>
>Sorry for the late reply, got sucked into JVMLS, and travel back, and
>now holiday (back on 27th).
>
>Thanks for experimenting with this. We pulled back from the
>Field/Array-specific handle experiments in a previous revision of the
>variable handle JEP because we knew we could do similar kinds of
>wrapping as you have shown. The idea being a VarHandle could be wrapped
>in a class that encapsulates the specific shape associated with a
>variable kind, and VarHandle becomes the primary place where unsafe
>access is corralled.
>
>Paul.
>
>On 8 Aug 2015, at 02:28, Peter Levart <peter.levart at gmail.com> wrote:
>
>> Hi,
>> 
>> @PolymorphicSignature methods in VarHandle (combined with generics in
>FieldHandle) are a way to expose an API that does not explode in the
>number of different public classes for different primitive types. But
>aren't any-fied (specialized) generics doing just the same? I know:
>VarHandles are  proposed for JDK9 and any-fied generics aren't there
>yet.
>> 
>> Anyway, I tried to see if current state of any-fied generics allows
>me to build an API that is similar in footprint as VarHandle but fully
>compile-time type safe:
>> 
>>
>http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/vaccess/VarAccessor.java
>> 
>> With some tricks (type tokens and manual specialization by
>sub-classing), it can be done as a type-safe wrapper over Unsafe. This
>implementation is missing proper access checks. It's just a proof of
>concept.
>> 
>> While playing with this, I noticed a javac inconsistency. The
>following diamond:
>> 
>> public abstract class VarAccessor<T, any V> {
>> 
>>    private static final Map<Class<?>, BiFunction<Class<?>, String,
>VarAccessor<?, any>>> factories
>>        = new HashMap<>();
>> 
>> ... does not work. I had to re-specify the full types in the HashMap
>constructor:
>> 
>>    private static final Map<Class<?>, BiFunction<Class<?>, String,
>VarAccessor<?, any>>> factories
>>        = new HashMap<Class<?>, BiFunction<Class<?>, String,
>VarAccessor<?, any>>>();
>> 
>> 
>> Regards, Peter
>> 


From john.r.rose at oracle.com  Tue Aug 18 06:44:54 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 17 Aug 2015 23:44:54 -0700
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
Message-ID: <D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>


> On Aug 7, 2015, at 1:55 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
>> 
>> Therefore even I use separate field to store the indexMask (entries.length
>> - 1) to avoid false sharing, the bounds check will effectively undo that
>> effort?
> 
> 
> Yes, anything that touches array.length can induce false sharing -- I
> mentioned this earlier in this thread :) :

I don't see that this particular case is a big problem.

If the workload consists of padded arrays, and if the first several
elements of each padded array A are left idle, then the array header
(including the field A.length) will be shared read-only.

The main risk is that an unrelated object X will be allocated *before*
the array header, and a field X.F toward the end of X will be mutable,
and will therefore cause conflicts with reads of A.length.

This risk is lessened because A is allocated with a certain amount
of alignment.  We could reduce it more if we added a rule (which we
don't have now) of aligning longer arrays more strongly.  There are
other reasons to do this as well, having to do with vector processing.

Anybody want to prototype some stronger array alignment logic?
It's tricky, but mostly straightforward, except for the extra checks on object
reallocation in the GC promotion logic.

> 
> I think any approach that requires reading the length of an array, whether
>> user or compiler inserted, is going to run afoul of possible false sharing;
>> only approach #3 would work since the mask field could be isolated to its
>> own cacheline.
> 
> The approach #3 you mentioned in the initial email could work *iff* JIT
> started const propagating final fields and then seeing that your mask
> guarantees an index < array.length *and* constant propagating the final
> field holding the array and knowing its length > 0 (assuming we're talking
> about a class with a final field array, which is true for typical
> ringbuffers).  Right now, only Unsafe can help avoiding range checks and
> false sharing.

Sorry, I think that's too many "iff"s.  We would have to store algebraic relations
between fields.  Doable but so complex that it would need a much more
spectacular payoff than just this use case.

Please, use the built-in A.length field as much as possible for your calculations,
because that is the field that all JVM versions are guaranteed to know about.

We know how to do the power-of-two range check trick, and intend to integrate it.

Side note #1:  It's not just power-of-two.  Any array length works the same, since
(a & b) <= b as long as (b >= 0), even if b+1 is not a power of two.  Perhaps one
reason we have been slow to integrate this optimization is that I have been
too eager to "capture" the full set of related identities.

Side note #2:  Paul Sandoz's talk last week at JVMLS showed that getting
better optimization for loops over unsafe accesses requires a surprisingly
small amount of special pleading.  He showed you can get a lot from an
intrinsic that reifies the same range check that is built into aaload, with
no further coupling to the actual Unsafe load.  It took me about five tries
to convince myself that it would really work.

? John

> 
> On Fri, Aug 7, 2015 at 4:41 PM, Michael Barker <mikeb01 at gmail.com> wrote:
> 
>> Hi Doug,
>> 
>> Thank you for that info. I've just realised something but want to check my
>> reasoning.  The bounds check is effectively doing:
>> 
>> if (index >= entries.length)
>>    throw ArrayOutOfBoundsException();
>> 
>> Therefore even I use separate field to store the indexMask (entries.length
>> - 1) to avoid false sharing, the bounds check will effectively undo that
>> effort?
>> 
>> Mike.
>> 
>> 
>> On 6 August 2015 at 02:12, Doug Lea <dl at cs.oswego.edu> wrote:
>> 
>>> On 08/04/2015 05:25 PM, Michael Barker wrote:
>>> 
>>> Thanks, I'll give that approach a try.  While it retains the padding on
>> the
>>>> array entries it is lost for entries.length, so while it won't share a
>>>> cache line with the array entries it could share it with some other
>> random
>>>> unknown thing.  I still have to run some more tests to see what the
>> actual
>>>> costs end up being.  I suspect that I'll just suck up the cost of the
>>>> bounds checking,
>>>> 
>>> 
>>> That's what I've ended up doing in similar cases in java.util.concurrent.
>>> It does add variance depending on placement across runs of
>>> programs as well as within runs when GC moves things. But not
>>> much more variance than you see from other memory placement
>>> effects and JVM noise.
>>> 
>>> It's worth reminding everyone that the need to do this
>>> stems from compiler limitations that in principle could
>>> be addressed someday. "Unsafe" access just means that
>>> the compiler cannot prove that an address is legal.
>>> It is frustrating that some cases that are obvious
>>> to their programmers cannot be proven -- as in an array
>>> that is only ever allocated with power-of-two size and
>>> accessed with masked indexing, but the allocation is outside
>>> the scope of compiler analysis.
>>> 
>>> High-quality bounds-check optimizations generally require
>>> internal type systems and static analyses that are too
>>> expensive for JITs. (See for example the work done in the
>>> ahead-of-time X10 compiler.) But with the planned demise
>>> of Unsafe, perhaps some people interested in optimization
>>> will be more motivated to try to invent some more effective
>>> JIT-friendly approximations.
>>> 
>>> -Doug
>>> 
>>> 
>>> 
>> 


From aleksey.shipilev at oracle.com  Tue Aug 18 12:01:06 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2015 15:01:06 +0300
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>	<55C219DB.2090104@cs.oswego.edu>	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
	<D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
Message-ID: <55D31E82.40202@oracle.com>

On 08/18/2015 09:44 AM, John Rose wrote:
> 
>> On Aug 7, 2015, at 1:55 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>>>
>>> Therefore even I use separate field to store the indexMask (entries.length
>>> - 1) to avoid false sharing, the bounds check will effectively undo that
>>> effort?
>>
>>
>> Yes, anything that touches array.length can induce false sharing -- I
>> mentioned this earlier in this thread :) :
> 
> I don't see that this particular case is a big problem.
> 
> If the workload consists of padded arrays, and if the first several
> elements of each padded array A are left idle, then the array header
> (including the field A.length) will be shared read-only.
> 
> The main risk is that an unrelated object X will be allocated *before*
> the array header, and a field X.F toward the end of X will be mutable,
> and will therefore cause conflicts with reads of A.length.
> 
> This risk is lessened because A is allocated with a certain amount
> of alignment.  We could reduce it more if we added a rule (which we
> don't have now) of aligning longer arrays more strongly.  There are
> other reasons to do this as well, having to do with vector processing.
> 
> Anybody want to prototype some stronger array alignment logic?
> It's tricky, but mostly straightforward, except for the extra checks on object
> reallocation in the GC promotion logic.

I am very doubtful about this endeavor. There is a recurrent dilemma:
should one pay for a reduced false sharing with a memory footprint hit?
False sharing evasion is a very special corner case, and so @Contended
pushes that question to users:

"* The effects of this annotation will nearly
 * always add significant space overhead to objects. The use of
 * {@code @Contended} is warranted only when the performance impact of
 * this time/space tradeoff is intrinsically worthwhile; for example,
 * in concurrent contexts in which each instance of the annotated
 * class is often accessed by a different thread.

For the example of arrays, whatever "enable threshold" is, it would
waste anything within [0; 2*cacheLine-2] bytes per array, for *all*
arrays over the threshold. You will never guess the threshold right for
all the usages, and most usages would pay footprint premium for nothing.

In other words, you can't win with heuristics. Therefore, there should
be an alignment hint that could indicate such an alignment constraint
for selected arrays/objects -- something for Panama to work out?

I further think that any band-aid before alignment hints are introduced
only distracts us from making the actual solution. Meanwhile, it seems
that globally optimal strategy is to "just" suck up the bounds check
costs, while waiting for the alignment hints.

Thanks,
-Aleksey


From dl at cs.oswego.edu  Tue Aug 18 13:51:06 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 18 Aug 2015 09:51:06 -0400
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>	<55C219DB.2090104@cs.oswego.edu>	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
	<D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
Message-ID: <55D3384A.8090203@cs.oswego.edu>

On 08/18/2015 02:44 AM, John Rose wrote:
>
>> On Aug 7, 2015, at 1:55 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>> Yes, anything that touches array.length can induce false sharing -- I
>> mentioned this earlier in this thread :) :
>
> I don't see that this particular case is a big problem.

It is a big problem only in that uncontrollable circumstances
cause unlikely/infrequent but huge slowdowns on big NUMA servers.

And it's a hard problem in part because on average, these effects
don't happen. On average padding is a bad idea. So false-sharing
control is a black art. The best we can do for non-arrays is pointwise
use of @Contended in cases with known high probabilityXimpact factors.
As Aleksey mentioned, nothing similar seems to apply for arrays
until Panama/layouts makes progress. Until then, it seems that this
will be a known limitation.

-Doug


From brian.goetz at oracle.com  Tue Aug 18 17:01:42 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 18 Aug 2015 13:01:42 -0400
Subject: See you at JVMLS
In-Reply-To: <55C628CA.8070506@oracle.com>
References: <55C628CA.8070506@oracle.com>
Message-ID: <55D364F6.2080407@oracle.com>

JVMLS talks up at:
   https://www.youtube.com/user/java


On 8/8/2015 12:05 PM, Brian Goetz wrote:
> I'll be doing a talk on the path from Model 1 to Model 2 (and a glimpse
> of Model 3) at JVMLS next week.  Hope to see some of you there.  Videos
> should go up on the Java YouTube channel fairly quickly after the
> conference.
>
> In the meantime ... I'll just note that we've had 50+ messages on the
> various "Model 2" threads and none of them started with "I tried it out
> and..."
>
> So a reminder ... the most valuable input the community can give in this
> process is to provide *actual experience reports*.  That's the main
> reason we make the significant investment in making the code and design
> sketches available early -- so that people can actually try it out, and
> help us see the holes that we might have missed.
>
>

From john.r.rose at oracle.com  Tue Aug 18 17:32:36 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 18 Aug 2015 10:32:36 -0700
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <55D3384A.8090203@cs.oswego.edu>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
	<D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
	<55D3384A.8090203@cs.oswego.edu>
Message-ID: <9EE1D805-02FD-43FA-B0BF-9786632201AD@oracle.com>

On Aug 18, 2015, at 6:51 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> It is a big problem only in that uncontrollable circumstances
> cause unlikely/infrequent but huge slowdowns on big NUMA servers.
> 
> And it's a hard problem in part because on average, these effects
> don't happen.

OK, got that.  Normal optimistic tactics don't help when you are walking
near a precipice in the fog.

> On average padding is a bad idea.


On Aug 18, 2015, at 5:01 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> For the example of arrays, whatever "enable threshold" is, it would
> waste anything within [0; 2*cacheLine-2] bytes per array, for *all*
> arrays over the threshold.

The "pad my arrays" idea can be formulated with a badness of epsilon,
by choosing a large-enough threshold.  But:

> You will never guess the threshold right for
> all the usages, and most usages would pay footprint premium for nothing.


Right.

OK, I'm catching up.  To apply the @Contended hack to a range-checked
structure, I guess we want a @Contended 'length' field, that is stored
deep past the header of the object.

This is not pure future.  Paul Sandoz showed at JVMLS a way
to use a var handle to embed a small array inside an object layout.

? John

From aleksey.shipilev at oracle.com  Tue Aug 18 18:10:22 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2015 21:10:22 +0300
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <9EE1D805-02FD-43FA-B0BF-9786632201AD@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
	<D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
	<55D3384A.8090203@cs.oswego.edu>
	<9EE1D805-02FD-43FA-B0BF-9786632201AD@oracle.com>
Message-ID: <55D3750E.4090209@oracle.com>

On 18.08.2015 20:32, John Rose wrote:
> OK, I'm catching up.  To apply the @Contended hack to a range-checked
> structure, I guess we want a @Contended 'length' field, that is stored
> deep past the header of the object.

Yeah, but @Contended is declaration-site.

Therefore:

 a) "length" should then be a synthetic field exposed to a classloader
and other class layout data, since @Contended operates there. But as of
now, "length" is the part of array header metadata, not the field block.
This is a technically intrusive, but contained change.

 b) you would want a "subclass" or a specialization of a particular
array to clearly mark what arrays should be contended. Otherwise, you
are playing the same game: penalizing everyone for a gain in the corner
case. This requires language changes.

If only @Contended was usable at use-sites, then we would be able to
mark individual arrays, and only facing problem (a). But that
prerequisite requires rewiring the entire @Contended machinery, which is
a problem (c) in itself.

Thanks,
-Aleksey



From palo.marton at gmail.com  Tue Aug 18 21:30:01 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Tue, 18 Aug 2015 21:30:01 +0000
Subject: See you at JVMLS
In-Reply-To: <55D364F6.2080407@oracle.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
Message-ID: <CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>

Thanks. I have just watched your talk on Valhalla. Just one curious
question on xxx$any interfaces: How do you handle this?

class Foo<any T> extends Bar { }

Foo$any instanceof Bar?
On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com> wrote:

> JVMLS talks up at:
>    https://www.youtube.com/user/java
>
>
> On 8/8/2015 12:05 PM, Brian Goetz wrote:
> > I'll be doing a talk on the path from Model 1 to Model 2 (and a glimpse
> > of Model 3) at JVMLS next week.  Hope to see some of you there.  Videos
> > should go up on the Java YouTube channel fairly quickly after the
> > conference.
> >
> > In the meantime ... I'll just note that we've had 50+ messages on the
> > various "Model 2" threads and none of them started with "I tried it out
> > and..."
> >
> > So a reminder ... the most valuable input the community can give in this
> > process is to provide *actual experience reports*.  That's the main
> > reason we make the significant investment in making the code and design
> > sketches available early -- so that people can actually try it out, and
> > help us see the holes that we might have missed.
> >
> >
>
-- 
Pavol Marton

From brian.goetz at oracle.com  Tue Aug 18 21:39:19 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 18 Aug 2015 17:39:19 -0400
Subject: See you at JVMLS
In-Reply-To: <CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
Message-ID: <55D3A607.2020101@oracle.com>

I'll sidestep your clever question by pointing out that the left operand 
of an instanceof check is an expression, not a type.

If you have:

     Foo<any> f = ...

     if (f instanceof Bar) { ... }

this works just fine, because all instantiations of Foo<T> are 
represented by classes whose supertype is Bar.  The harder question is 
the reflective one (Class.isAssignableFrom.)  But reflection is still a 
work in progress (as is the whole thing, of course.)

On 8/18/2015 5:30 PM, Palo Marton wrote:
> Thanks. I have just watched your talk on Valhalla. Just one curious
> question on xxx$any interfaces: How do you handle this?
>
> class Foo<any T> extends Bar { }
>
> Foo$any instanceof Bar?
> On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     JVMLS talks up at:
>     https://www.youtube.com/user/java
>
>
>     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>      > I'll be doing a talk on the path from Model 1 to Model 2 (and a
>     glimpse
>      > of Model 3) at JVMLS next week.  Hope to see some of you there.
>     Videos
>      > should go up on the Java YouTube channel fairly quickly after the
>      > conference.
>      >
>      > In the meantime ... I'll just note that we've had 50+ messages on the
>      > various "Model 2" threads and none of them started with "I tried
>     it out
>      > and..."
>      >
>      > So a reminder ... the most valuable input the community can give
>     in this
>      > process is to provide *actual experience reports*.  That's the main
>      > reason we make the significant investment in making the code and
>     design
>      > sketches available early -- so that people can actually try it
>     out, and
>      > help us see the holes that we might have missed.
>      >
>      >
>
> --
> Pavol Marton

From mikeb01 at gmail.com  Tue Aug 18 21:48:06 2015
From: mikeb01 at gmail.com (Michael Barker)
Date: Wed, 19 Aug 2015 09:48:06 +1200
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <55D3750E.4090209@oracle.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
	<D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
	<55D3384A.8090203@cs.oswego.edu>
	<9EE1D805-02FD-43FA-B0BF-9786632201AD@oracle.com>
	<55D3750E.4090209@oracle.com>
Message-ID: <CALwNKeTUd7ECEU+wKHKoq_oeOpHa6upwaHa8PQV2hr1WB08YaA@mail.gmail.com>

>
> On 18.08.2015 20:32, John Rose wrote:
> > OK, I'm catching up.  To apply the @Contended hack to a range-checked
> > structure, I guess we want a @Contended 'length' field, that is stored
> > deep past the header of the object.
>

Also a gentle reminder that @Contended is not useful for libraries outside
of the JDK, due it being defaulted off.  So for it to be part of a viable
alternative to Unsafe, you would need to cost in the work needed to flip
the default (security auditing required if I remember correctly).

Mike.

From palo.marton at gmail.com  Tue Aug 18 21:49:07 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Tue, 18 Aug 2015 21:49:07 +0000
Subject: See you at JVMLS
In-Reply-To: <55D3A607.2020101@oracle.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
Message-ID: <CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>

Yes, that's a nice sidestep ;-)
My question was meant in a general way, not only about results of
instanceof/isAssignableFrom. What about methods of Bar? Will you recreate
them in Foo$any? What about eg call to
f.barMethod()?
On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com> wrote:

> I'll sidestep your clever question by pointing out that the left operand
> of an instanceof check is an expression, not a type.
>
> If you have:
>
>      Foo<any> f = ...
>
>      if (f instanceof Bar) { ... }
>
> this works just fine, because all instantiations of Foo<T> are
> represented by classes whose supertype is Bar.  The harder question is
> the reflective one (Class.isAssignableFrom.)  But reflection is still a
> work in progress (as is the whole thing, of course.)
>
> On 8/18/2015 5:30 PM, Palo Marton wrote:
> > Thanks. I have just watched your talk on Valhalla. Just one curious
> > question on xxx$any interfaces: How do you handle this?
> >
> > class Foo<any T> extends Bar { }
> >
> > Foo$any instanceof Bar?
> > On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com
> > <mailto:brian.goetz at oracle.com>> wrote:
> >
> >     JVMLS talks up at:
> >     https://www.youtube.com/user/java
> >
> >
> >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
> >      > I'll be doing a talk on the path from Model 1 to Model 2 (and a
> >     glimpse
> >      > of Model 3) at JVMLS next week.  Hope to see some of you there.
> >     Videos
> >      > should go up on the Java YouTube channel fairly quickly after the
> >      > conference.
> >      >
> >      > In the meantime ... I'll just note that we've had 50+ messages on
> the
> >      > various "Model 2" threads and none of them started with "I tried
> >     it out
> >      > and..."
> >      >
> >      > So a reminder ... the most valuable input the community can give
> >     in this
> >      > process is to provide *actual experience reports*.  That's the
> main
> >      > reason we make the significant investment in making the code and
> >     design
> >      > sketches available early -- so that people can actually try it
> >     out, and
> >      > help us see the holes that we might have missed.
> >      >
> >      >
> >
> > --
> > Pavol Marton
>
-- 
Pavol Marton

From brian.goetz at oracle.com  Tue Aug 18 21:53:21 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 18 Aug 2015 17:53:21 -0400
Subject: See you at JVMLS
In-Reply-To: <CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
Message-ID: <55D3A951.7040105@oracle.com>

Yes, that has to work, though it doesn't currently.  On the list...

On 8/18/2015 5:49 PM, Palo Marton wrote:
> Yes, that's a nice sidestep ;-)
> My question was meant in a general way, not only about results of
> instanceof/isAssignableFrom. What about methods of Bar? Will you
> recreate them in Foo$any? What about eg call to
> f.barMethod()?
> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     I'll sidestep your clever question by pointing out that the left operand
>     of an instanceof check is an expression, not a type.
>
>     If you have:
>
>           Foo<any> f = ...
>
>           if (f instanceof Bar) { ... }
>
>     this works just fine, because all instantiations of Foo<T> are
>     represented by classes whose supertype is Bar.  The harder question is
>     the reflective one (Class.isAssignableFrom.)  But reflection is still a
>     work in progress (as is the whole thing, of course.)
>
>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>      > Thanks. I have just watched your talk on Valhalla. Just one curious
>      > question on xxx$any interfaces: How do you handle this?
>      >
>      > class Foo<any T> extends Bar { }
>      >
>      > Foo$any instanceof Bar?
>      > On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com
>     <mailto:brian.goetz at oracle.com>
>      > <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>>
>     wrote:
>      >
>      >     JVMLS talks up at:
>      > https://www.youtube.com/user/java
>      >
>      >
>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>      >      > I'll be doing a talk on the path from Model 1 to Model 2
>     (and a
>      >     glimpse
>      >      > of Model 3) at JVMLS next week.  Hope to see some of you
>     there.
>      >     Videos
>      >      > should go up on the Java YouTube channel fairly quickly
>     after the
>      >      > conference.
>      >      >
>      >      > In the meantime ... I'll just note that we've had 50+
>     messages on the
>      >      > various "Model 2" threads and none of them started with "I
>     tried
>      >     it out
>      >      > and..."
>      >      >
>      >      > So a reminder ... the most valuable input the community
>     can give
>      >     in this
>      >      > process is to provide *actual experience reports*.  That's
>     the main
>      >      > reason we make the significant investment in making the
>     code and
>      >     design
>      >      > sketches available early -- so that people can actually try it
>      >     out, and
>      >      > help us see the holes that we might have missed.
>      >      >
>      >      >
>      >
>      > --
>      > Pavol Marton
>
> --
> Pavol Marton

From palo.marton at gmail.com  Tue Aug 18 21:57:27 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Tue, 18 Aug 2015 21:57:27 +0000
Subject: See you at JVMLS
In-Reply-To: <55D3A951.7040105@oracle.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
Message-ID: <CAPWSNUkOQBF_gS=t1OuKVUDp-BCX8pygOaC3NuieM7A3hJ3Y8w@mail.gmail.com>

One option is to not recreate them, but to compile such construct as
((Bar)f).barMethod(). May be that can work. But reflection will get even
more ugly :(
On ut, 18. aug 2015 at 23:53 Brian Goetz <brian.goetz at oracle.com> wrote:

> Yes, that has to work, though it doesn't currently.  On the list...
>
> On 8/18/2015 5:49 PM, Palo Marton wrote:
> > Yes, that's a nice sidestep ;-)
> > My question was meant in a general way, not only about results of
> > instanceof/isAssignableFrom. What about methods of Bar? Will you
> > recreate them in Foo$any? What about eg call to
> > f.barMethod()?
> > On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
> > <mailto:brian.goetz at oracle.com>> wrote:
> >
> >     I'll sidestep your clever question by pointing out that the left
> operand
> >     of an instanceof check is an expression, not a type.
> >
> >     If you have:
> >
> >           Foo<any> f = ...
> >
> >           if (f instanceof Bar) { ... }
> >
> >     this works just fine, because all instantiations of Foo<T> are
> >     represented by classes whose supertype is Bar.  The harder question
> is
> >     the reflective one (Class.isAssignableFrom.)  But reflection is
> still a
> >     work in progress (as is the whole thing, of course.)
> >
> >     On 8/18/2015 5:30 PM, Palo Marton wrote:
> >      > Thanks. I have just watched your talk on Valhalla. Just one
> curious
> >      > question on xxx$any interfaces: How do you handle this?
> >      >
> >      > class Foo<any T> extends Bar { }
> >      >
> >      > Foo$any instanceof Bar?
> >      > On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com
> >     <mailto:brian.goetz at oracle.com>
> >      > <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>>
> >     wrote:
> >      >
> >      >     JVMLS talks up at:
> >      > https://www.youtube.com/user/java
> >      >
> >      >
> >      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
> >      >      > I'll be doing a talk on the path from Model 1 to Model 2
> >     (and a
> >      >     glimpse
> >      >      > of Model 3) at JVMLS next week.  Hope to see some of you
> >     there.
> >      >     Videos
> >      >      > should go up on the Java YouTube channel fairly quickly
> >     after the
> >      >      > conference.
> >      >      >
> >      >      > In the meantime ... I'll just note that we've had 50+
> >     messages on the
> >      >      > various "Model 2" threads and none of them started with "I
> >     tried
> >      >     it out
> >      >      > and..."
> >      >      >
> >      >      > So a reminder ... the most valuable input the community
> >     can give
> >      >     in this
> >      >      > process is to provide *actual experience reports*.  That's
> >     the main
> >      >      > reason we make the significant investment in making the
> >     code and
> >      >     design
> >      >      > sketches available early -- so that people can actually
> try it
> >      >     out, and
> >      >      > help us see the holes that we might have missed.
> >      >      >
> >      >      >
> >      >
> >      > --
> >      > Pavol Marton
> >
> > --
> > Pavol Marton
>
-- 
Pavol Marton

From john.r.rose at oracle.com  Tue Aug 18 21:59:52 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 18 Aug 2015 14:59:52 -0700
Subject: VarHandles & LMAX Disruptor
In-Reply-To: <CALwNKeTUd7ECEU+wKHKoq_oeOpHa6upwaHa8PQV2hr1WB08YaA@mail.gmail.com>
References: <CALwNKeSpZSkhuQUd7xHctibLof59Y7SxOhxP_0Y6bWDBLA4rzA@mail.gmail.com>
	<5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com>
	<CALwNKeQ9NPCUec2wydL77rwLv429ONFhUsubNr3uNYiVRM9Biw@mail.gmail.com>
	<4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com>
	<CALwNKeRBJo--zwrNwzL9mChDnuBw_yuH+5PspEkonZA96VFvtQ@mail.gmail.com>
	<E6A37B18-7BD0-4761-8E45-D90CE6876173@oracle.com>
	<CALwNKeS06phqjtttHsQfp3qzuKLC_u1fJPTfrYDvwrDBVyXi+Q@mail.gmail.com>
	<55C219DB.2090104@cs.oswego.edu>
	<CALwNKeQ=3aYTiP_8JStNO8m1kd6197tbzToCA=MX0UZpbaJ87Q@mail.gmail.com>
	<CAHjP37EJmjzy51n8P46OXLhvNrbkifuLNc4edHX18S8FDBoz9Q@mail.gmail.com>
	<D5D26022-9907-4597-A2A5-AB7C19CDB01B@oracle.com>
	<55D3384A.8090203@cs.oswego.edu>
	<9EE1D805-02FD-43FA-B0BF-9786632201AD@oracle.com>
	<55D3750E.4090209@oracle.com>
	<CALwNKeTUd7ECEU+wKHKoq_oeOpHa6upwaHa8PQV2hr1WB08YaA@mail.gmail.com>
Message-ID: <A3075240-5EEC-411A-B24E-AC8F70BC9AD4@oracle.com>

On Aug 18, 2015, at 2:48 PM, Michael Barker <mikeb01 at gmail.com> wrote:
> 
> On 18.08.2015 20:32, John Rose wrote:
> > OK, I'm catching up.  To apply the @Contended hack to a range-checked
> > structure, I guess we want a @Contended 'length' field, that is stored
> > deep past the header of the object.
> 
> Also a gentle reminder that @Contended is not useful for libraries outside of the JDK, due it being defaulted off.  So for it to be part of a viable alternative to Unsafe, you would need to cost in the work needed to flip the default (security auditing required if I remember correctly).

Yes; I'm assuming some sort of built-in array-like type, living in a place like java.util.concurrent.  ? John


From forax at univ-mlv.fr  Tue Aug 18 21:59:53 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 18 Aug 2015 21:59:53 +0000
Subject: See you at JVMLS
In-Reply-To: <55D3A951.7040105@oracle.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
Message-ID: <B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>

It can not work because if the method in B is package visible it should in Foo$any or not depending if the code that use Foo$any is in the same package as B or not.

regards,
R?mi 

Le 18 ao?t 2015 23:53:21 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>Yes, that has to work, though it doesn't currently.  On the list...
>
>On 8/18/2015 5:49 PM, Palo Marton wrote:
>> Yes, that's a nice sidestep ;-)
>> My question was meant in a general way, not only about results of
>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>> recreate them in Foo$any? What about eg call to
>> f.barMethod()?
>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>>
>>     I'll sidestep your clever question by pointing out that the left
>operand
>>     of an instanceof check is an expression, not a type.
>>
>>     If you have:
>>
>>           Foo<any> f = ...
>>
>>           if (f instanceof Bar) { ... }
>>
>>     this works just fine, because all instantiations of Foo<T> are
>>     represented by classes whose supertype is Bar.  The harder
>question is
>>     the reflective one (Class.isAssignableFrom.)  But reflection is
>still a
>>     work in progress (as is the whole thing, of course.)
>>
>>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>>      > Thanks. I have just watched your talk on Valhalla. Just one
>curious
>>      > question on xxx$any interfaces: How do you handle this?
>>      >
>>      > class Foo<any T> extends Bar { }
>>      >
>>      > Foo$any instanceof Bar?
>>      > On ut, 18. aug 2015 at 19:02 Brian Goetz
><brian.goetz at oracle.com
>>     <mailto:brian.goetz at oracle.com>
>>      > <mailto:brian.goetz at oracle.com
><mailto:brian.goetz at oracle.com>>>
>>     wrote:
>>      >
>>      >     JVMLS talks up at:
>>      > https://www.youtube.com/user/java
>>      >
>>      >
>>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>      >      > I'll be doing a talk on the path from Model 1 to Model
>2
>>     (and a
>>      >     glimpse
>>      >      > of Model 3) at JVMLS next week.  Hope to see some of
>you
>>     there.
>>      >     Videos
>>      >      > should go up on the Java YouTube channel fairly quickly
>>     after the
>>      >      > conference.
>>      >      >
>>      >      > In the meantime ... I'll just note that we've had 50+
>>     messages on the
>>      >      > various "Model 2" threads and none of them started with
>"I
>>     tried
>>      >     it out
>>      >      > and..."
>>      >      >
>>      >      > So a reminder ... the most valuable input the community
>>     can give
>>      >     in this
>>      >      > process is to provide *actual experience reports*. 
>That's
>>     the main
>>      >      > reason we make the significant investment in making the
>>     code and
>>      >     design
>>      >      > sketches available early -- so that people can actually
>try it
>>      >     out, and
>>      >      > help us see the holes that we might have missed.
>>      >      >
>>      >      >
>>      >
>>      > --
>>      > Pavol Marton
>>
>> --
>> Pavol Marton


From forax at univ-mlv.fr  Tue Aug 18 22:19:41 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 18 Aug 2015 22:19:41 +0000
Subject: See you at JVMLS
In-Reply-To: <B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
	<B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>
Message-ID: <4C579C2B-D31B-47FB-ABE8-B830757FDD66@univ-mlv.fr>

I should have mentioned that i have not found the time yet to see the presentation on valhalla so sorry if i say something stupid.

cheers,
R?mi 

Le 18 ao?t 2015 23:59:53 CEST, "R?mi Forax" <forax at univ-mlv.fr> a ?crit :
>It can not work because if the method in B is package visible it should
>in Foo$any or not depending if the code that use Foo$any is in the same
>package as B or not.
>
>regards,
>R?mi 
>
>Le 18 ao?t 2015 23:53:21 CEST, Brian Goetz <brian.goetz at oracle.com> a
>?crit :
>>Yes, that has to work, though it doesn't currently.  On the list...
>>
>>On 8/18/2015 5:49 PM, Palo Marton wrote:
>>> Yes, that's a nice sidestep ;-)
>>> My question was meant in a general way, not only about results of
>>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>>> recreate them in Foo$any? What about eg call to
>>> f.barMethod()?
>>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>     I'll sidestep your clever question by pointing out that the left
>>operand
>>>     of an instanceof check is an expression, not a type.
>>>
>>>     If you have:
>>>
>>>           Foo<any> f = ...
>>>
>>>           if (f instanceof Bar) { ... }
>>>
>>>     this works just fine, because all instantiations of Foo<T> are
>>>     represented by classes whose supertype is Bar.  The harder
>>question is
>>>     the reflective one (Class.isAssignableFrom.)  But reflection is
>>still a
>>>     work in progress (as is the whole thing, of course.)
>>>
>>>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>>>      > Thanks. I have just watched your talk on Valhalla. Just one
>>curious
>>>      > question on xxx$any interfaces: How do you handle this?
>>>      >
>>>      > class Foo<any T> extends Bar { }
>>>      >
>>>      > Foo$any instanceof Bar?
>>>      > On ut, 18. aug 2015 at 19:02 Brian Goetz
>><brian.goetz at oracle.com
>>>     <mailto:brian.goetz at oracle.com>
>>>      > <mailto:brian.goetz at oracle.com
>><mailto:brian.goetz at oracle.com>>>
>>>     wrote:
>>>      >
>>>      >     JVMLS talks up at:
>>>      > https://www.youtube.com/user/java
>>>      >
>>>      >
>>>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>>      >      > I'll be doing a talk on the path from Model 1 to Model
>>2
>>>     (and a
>>>      >     glimpse
>>>      >      > of Model 3) at JVMLS next week.  Hope to see some of
>>you
>>>     there.
>>>      >     Videos
>>>      >      > should go up on the Java YouTube channel fairly
>quickly
>>>     after the
>>>      >      > conference.
>>>      >      >
>>>      >      > In the meantime ... I'll just note that we've had 50+
>>>     messages on the
>>>      >      > various "Model 2" threads and none of them started
>with
>>"I
>>>     tried
>>>      >     it out
>>>      >      > and..."
>>>      >      >
>>>      >      > So a reminder ... the most valuable input the
>community
>>>     can give
>>>      >     in this
>>>      >      > process is to provide *actual experience reports*. 
>>That's
>>>     the main
>>>      >      > reason we make the significant investment in making
>the
>>>     code and
>>>      >     design
>>>      >      > sketches available early -- so that people can
>actually
>>try it
>>>      >     out, and
>>>      >      > help us see the holes that we might have missed.
>>>      >      >
>>>      >      >
>>>      >
>>>      > --
>>>      > Pavol Marton
>>>
>>> --
>>> Pavol Marton


From stef at epardaud.fr  Wed Aug 19 10:09:39 2015
From: stef at epardaud.fr (Stephane Epardaud)
Date: Wed, 19 Aug 2015 12:09:39 +0200
Subject: "Model 2" prototype status
In-Reply-To: <55C0E345.4050503@oracle.com>
References: <55BBD188.8020406@oracle.com>	<03042D68-AE00-40FA-B396-8954B91F07B9@univ-mlv.fr>	<55BD3E97.3020206@oracle.com>	<302A8AD7-F556-481D-811F-B787F412F866@univ-mlv.fr>	<55beaec6.50ceb40a.3dcbf.ffffda83@mx.google.com>	<D123D436-ACB7-4A5C-85A4-37398261E010@oracle.com>	<55BF81F4.7010400@oracle.com>
	<1438699645.4725.33.camel@sludev.com> <55C0E345.4050503@oracle.com>
Message-ID: <55D455E3.8030201@epardaud.fr>

Well, I'm glad some people did ask questions about things you had
already considered and discarded with the first prototype because it
appears that the new model fixes all these issues we raised :)

The introduction of a common supertype via any-wildcards with autoboxing
is great and exactly what was missing. The introduction of private
methods in interfaces in the VM is also a good side-effect. And having
seen your JVMLS talk I'm pretty enthoused by the third part that you
guys are working on to make code sharing better at the VM level.

So congrats!

On 04/08/15 18:07, Brian Goetz wrote:
> And I regret to say, I won't be able to continue this discussion
> further; extended discussions on "why not take a completely different
> direction" -- especially when that direction is one we've already
> considered -- are just too much of a distraction, so please, hold your
> responses. 



From brian.goetz at oracle.com  Wed Aug 19 13:50:57 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 19 Aug 2015 09:50:57 -0400
Subject: See you at JVMLS
In-Reply-To: <9F385DE9-10A8-4C67-A1CF-00F5A203015C@online.de>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
	<B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>
	<4C579C2B-D31B-47FB-ABE8-B830757FDD66@univ-mlv.fr>
	<9F385DE9-10A8-4C67-A1CF-00F5A203015C@online.de>
Message-ID: <55D489C1.2040500@oracle.com>


> Of course, nobody knows, when valhalla will actually be reality...
> ?but is someone willing to make a guess maybe ?

I can tell you for sure it won't be part of Java 9.  Other than that, we 
are not making any projections.

> Maybe even more important: Will it ever be reality ? Is it just a prove-of-concept ?
> Or, to increase the pressure: Is Oracle willing to invest so much effort (we hope badly =)) ?

Oracle is indeed investing actively in this.  The JVMLS talk outlines 
where we are now; clearly we've got a long way to go, but we're pleased 
with the progress so far.  Stay tuned...

Cheers,
-Brian


From peter.levart at gmail.com  Wed Aug 19 14:38:22 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Aug 2015 16:38:22 +0200
Subject: See you at JVMLS
In-Reply-To: <55D3A951.7040105@oracle.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
Message-ID: <55D494DE.30906@gmail.com>

Hm,

If you recreate methods from Bar in Foo$any interface, then any change 
of such method in Bar (addition, signature change, ...) will be binary 
incompatible with separate compilation of Foo even though such method is 
not referenced anywhere in Foo (neither overridden nor called).

Perhaps the Foo$any could be generated by class spinning at runtime as 
apposed to be generated by javac when Foo is compiled.

Peter

On 08/18/2015 11:53 PM, Brian Goetz wrote:
> Yes, that has to work, though it doesn't currently.  On the list...
>
> On 8/18/2015 5:49 PM, Palo Marton wrote:
>> Yes, that's a nice sidestep ;-)
>> My question was meant in a general way, not only about results of
>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>> recreate them in Foo$any? What about eg call to
>> f.barMethod()?
>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>>
>>     I'll sidestep your clever question by pointing out that the left 
>> operand
>>     of an instanceof check is an expression, not a type.
>>
>>     If you have:
>>
>>           Foo<any> f = ...
>>
>>           if (f instanceof Bar) { ... }
>>
>>     this works just fine, because all instantiations of Foo<T> are
>>     represented by classes whose supertype is Bar.  The harder 
>> question is
>>     the reflective one (Class.isAssignableFrom.)  But reflection is 
>> still a
>>     work in progress (as is the whole thing, of course.)
>>
>>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>>      > Thanks. I have just watched your talk on Valhalla. Just one 
>> curious
>>      > question on xxx$any interfaces: How do you handle this?
>>      >
>>      > class Foo<any T> extends Bar { }
>>      >
>>      > Foo$any instanceof Bar?
>>      > On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com
>>     <mailto:brian.goetz at oracle.com>
>>      > <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>>
>>     wrote:
>>      >
>>      >     JVMLS talks up at:
>>      > https://www.youtube.com/user/java
>>      >
>>      >
>>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>      >      > I'll be doing a talk on the path from Model 1 to Model 2
>>     (and a
>>      >     glimpse
>>      >      > of Model 3) at JVMLS next week.  Hope to see some of you
>>     there.
>>      >     Videos
>>      >      > should go up on the Java YouTube channel fairly quickly
>>     after the
>>      >      > conference.
>>      >      >
>>      >      > In the meantime ... I'll just note that we've had 50+
>>     messages on the
>>      >      > various "Model 2" threads and none of them started with "I
>>     tried
>>      >     it out
>>      >      > and..."
>>      >      >
>>      >      > So a reminder ... the most valuable input the community
>>     can give
>>      >     in this
>>      >      > process is to provide *actual experience reports*.  That's
>>     the main
>>      >      > reason we make the significant investment in making the
>>     code and
>>      >     design
>>      >      > sketches available early -- so that people can actually 
>> try it
>>      >     out, and
>>      >      > help us see the holes that we might have missed.
>>      >      >
>>      >      >
>>      >
>>      > --
>>      > Pavol Marton
>>
>> -- 
>> Pavol Marton


From peter.levart at gmail.com  Wed Aug 19 14:39:46 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Aug 2015 16:39:46 +0200
Subject: See you at JVMLS
In-Reply-To: <55D494DE.30906@gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com> <55D494DE.30906@gmail.com>
Message-ID: <55D49532.8010101@gmail.com>



On 08/19/2015 04:38 PM, Peter Levart wrote:
> Hm,
>
> If you recreate methods from Bar in Foo$any interface, then any change 
> of such method in Bar (addition, signature change, ...) will 

pardon: addition -> removal

> be binary incompatible with separate compilation of Foo even though 
> such method is not referenced anywhere in Foo (neither overridden nor 
> called).
>
> Perhaps the Foo$any could be generated by class spinning at runtime as 
> apposed to be generated by javac when Foo is compiled.
>
> Peter
>
> On 08/18/2015 11:53 PM, Brian Goetz wrote:
>> Yes, that has to work, though it doesn't currently.  On the list...
>>
>> On 8/18/2015 5:49 PM, Palo Marton wrote:
>>> Yes, that's a nice sidestep ;-)
>>> My question was meant in a general way, not only about results of
>>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>>> recreate them in Foo$any? What about eg call to
>>> f.barMethod()?
>>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>     I'll sidestep your clever question by pointing out that the left 
>>> operand
>>>     of an instanceof check is an expression, not a type.
>>>
>>>     If you have:
>>>
>>>           Foo<any> f = ...
>>>
>>>           if (f instanceof Bar) { ... }
>>>
>>>     this works just fine, because all instantiations of Foo<T> are
>>>     represented by classes whose supertype is Bar.  The harder 
>>> question is
>>>     the reflective one (Class.isAssignableFrom.)  But reflection is 
>>> still a
>>>     work in progress (as is the whole thing, of course.)
>>>
>>>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>>>      > Thanks. I have just watched your talk on Valhalla. Just one 
>>> curious
>>>      > question on xxx$any interfaces: How do you handle this?
>>>      >
>>>      > class Foo<any T> extends Bar { }
>>>      >
>>>      > Foo$any instanceof Bar?
>>>      > On ut, 18. aug 2015 at 19:02 Brian Goetz <brian.goetz at oracle.com
>>>     <mailto:brian.goetz at oracle.com>
>>>      > <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>>
>>>     wrote:
>>>      >
>>>      >     JVMLS talks up at:
>>>      > https://www.youtube.com/user/java
>>>      >
>>>      >
>>>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>>      >      > I'll be doing a talk on the path from Model 1 to Model 2
>>>     (and a
>>>      >     glimpse
>>>      >      > of Model 3) at JVMLS next week.  Hope to see some of you
>>>     there.
>>>      >     Videos
>>>      >      > should go up on the Java YouTube channel fairly quickly
>>>     after the
>>>      >      > conference.
>>>      >      >
>>>      >      > In the meantime ... I'll just note that we've had 50+
>>>     messages on the
>>>      >      > various "Model 2" threads and none of them started 
>>> with "I
>>>     tried
>>>      >     it out
>>>      >      > and..."
>>>      >      >
>>>      >      > So a reminder ... the most valuable input the community
>>>     can give
>>>      >     in this
>>>      >      > process is to provide *actual experience reports*.  
>>> That's
>>>     the main
>>>      >      > reason we make the significant investment in making the
>>>     code and
>>>      >     design
>>>      >      > sketches available early -- so that people can 
>>> actually try it
>>>      >     out, and
>>>      >      > help us see the holes that we might have missed.
>>>      >      >
>>>      >      >
>>>      >
>>>      > --
>>>      > Pavol Marton
>>>
>>> -- 
>>> Pavol Marton
>


From peter.levart at gmail.com  Wed Aug 19 14:55:18 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Aug 2015 16:55:18 +0200
Subject: See you at JVMLS
In-Reply-To: <B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
	<B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>
Message-ID: <55D498D6.5080906@gmail.com>



On 08/18/2015 11:59 PM, R?mi Forax wrote:
> It can not work because if the method in B is package visible it should in Foo$any or not depending if the code that use Foo$any is in the same package as B or not.

That's a problem. There would have to be a Bar$any interface with 
methods from Bar (and Foo$any extends Bar$any) even though Bar is not 
using "any T" generics in it's declaration...

Also, if Foo<any>.class is an interface, one could create a:

      Foo<any> proxy = Proxy.newProxyInstance(..., new Class<?>[] { 
Foo<any>.class }, ...);

and try to assign:

     Bar bar = proxy;

So it seems that Bar.class.isAssignableFrom(Foo<any>.class) would have 
to return false...

Peter

>
> regards,
> R?mi
>
> Le 18 ao?t 2015 23:53:21 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>> Yes, that has to work, though it doesn't currently.  On the list...
>>
>> On 8/18/2015 5:49 PM, Palo Marton wrote:
>>> Yes, that's a nice sidestep ;-)
>>> My question was meant in a general way, not only about results of
>>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>>> recreate them in Foo$any? What about eg call to
>>> f.barMethod()?
>>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>      I'll sidestep your clever question by pointing out that the left
>> operand
>>>      of an instanceof check is an expression, not a type.
>>>
>>>      If you have:
>>>
>>>            Foo<any> f = ...
>>>
>>>            if (f instanceof Bar) { ... }
>>>
>>>      this works just fine, because all instantiations of Foo<T> are
>>>      represented by classes whose supertype is Bar.  The harder
>> question is
>>>      the reflective one (Class.isAssignableFrom.)  But reflection is
>> still a
>>>      work in progress (as is the whole thing, of course.)
>>>
>>>      On 8/18/2015 5:30 PM, Palo Marton wrote:
>>>       > Thanks. I have just watched your talk on Valhalla. Just one
>> curious
>>>       > question on xxx$any interfaces: How do you handle this?
>>>       >
>>>       > class Foo<any T> extends Bar { }
>>>       >
>>>       > Foo$any instanceof Bar?
>>>       > On ut, 18. aug 2015 at 19:02 Brian Goetz
>> <brian.goetz at oracle.com
>>>      <mailto:brian.goetz at oracle.com>
>>>       > <mailto:brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>>>
>>>      wrote:
>>>       >
>>>       >     JVMLS talks up at:
>>>       > https://www.youtube.com/user/java
>>>       >
>>>       >
>>>       >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>>       >      > I'll be doing a talk on the path from Model 1 to Model
>> 2
>>>      (and a
>>>       >     glimpse
>>>       >      > of Model 3) at JVMLS next week.  Hope to see some of
>> you
>>>      there.
>>>       >     Videos
>>>       >      > should go up on the Java YouTube channel fairly quickly
>>>      after the
>>>       >      > conference.
>>>       >      >
>>>       >      > In the meantime ... I'll just note that we've had 50+
>>>      messages on the
>>>       >      > various "Model 2" threads and none of them started with
>> "I
>>>      tried
>>>       >     it out
>>>       >      > and..."
>>>       >      >
>>>       >      > So a reminder ... the most valuable input the community
>>>      can give
>>>       >     in this
>>>       >      > process is to provide *actual experience reports*.
>> That's
>>>      the main
>>>       >      > reason we make the significant investment in making the
>>>      code and
>>>       >     design
>>>       >      > sketches available early -- so that people can actually
>> try it
>>>       >     out, and
>>>       >      > help us see the holes that we might have missed.
>>>       >      >
>>>       >      >
>>>       >
>>>       > --
>>>       > Pavol Marton
>>>
>>> --
>>> Pavol Marton


From chris at hazelcast.com  Wed Aug 19 15:28:10 2015
From: chris at hazelcast.com (Christoph Engelbert)
Date: Wed, 19 Aug 2015 17:28:10 +0200
Subject: See you at JVMLS
In-Reply-To: <55D498D6.5080906@gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com>
	<B340F6BD-93C2-4FCF-B433-AF0E7905373A@univ-mlv.fr>
	<55D498D6.5080906@gmail.com>
Message-ID: <E579C553-8DF1-408F-960A-6B7667544482@hazelcast.com>

Hey Peter,

Interesting catch but as long as Bar doesn?t have any generic methods why do we have to create a generalized class? Methods won?t be generalized anyways, do they? I have the feeling I?m missing something in your explanation :)

Chris



> On 19 Aug 2015, at 16:55, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 08/18/2015 11:59 PM, R?mi Forax wrote:
>> It can not work because if the method in B is package visible it should in Foo$any or not depending if the code that use Foo$any is in the same package as B or not.
> 
> That's a problem. There would have to be a Bar$any interface with methods from Bar (and Foo$any extends Bar$any) even though Bar is not using "any T" generics in it's declaration...
> 
> Also, if Foo<any>.class is an interface, one could create a:
> 
>     Foo<any> proxy = Proxy.newProxyInstance(..., new Class<?>[] { Foo<any>.class }, ...);
> 
> and try to assign:
> 
>    Bar bar = proxy;
> 
> So it seems that Bar.class.isAssignableFrom(Foo<any>.class) would have to return false...
> 
> Peter
> 
>> 
>> regards,
>> R?mi
>> 
>> Le 18 ao?t 2015 23:53:21 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>>> Yes, that has to work, though it doesn't currently.  On the list...
>>> 
>>> On 8/18/2015 5:49 PM, Palo Marton wrote:
>>>> Yes, that's a nice sidestep ;-)
>>>> My question was meant in a general way, not only about results of
>>>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>>>> recreate them in Foo$any? What about eg call to
>>>> f.barMethod()?
>>>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>> 
>>>>     I'll sidestep your clever question by pointing out that the left
>>> operand
>>>>     of an instanceof check is an expression, not a type.
>>>> 
>>>>     If you have:
>>>> 
>>>>           Foo<any> f = ...
>>>> 
>>>>           if (f instanceof Bar) { ... }
>>>> 
>>>>     this works just fine, because all instantiations of Foo<T> are
>>>>     represented by classes whose supertype is Bar.  The harder
>>> question is
>>>>     the reflective one (Class.isAssignableFrom.)  But reflection is
>>> still a
>>>>     work in progress (as is the whole thing, of course.)
>>>> 
>>>>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>>>>      > Thanks. I have just watched your talk on Valhalla. Just one
>>> curious
>>>>      > question on xxx$any interfaces: How do you handle this?
>>>>      >
>>>>      > class Foo<any T> extends Bar { }
>>>>      >
>>>>      > Foo$any instanceof Bar?
>>>>      > On ut, 18. aug 2015 at 19:02 Brian Goetz
>>> <brian.goetz at oracle.com
>>>>     <mailto:brian.goetz at oracle.com>
>>>>      > <mailto:brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>>>
>>>>     wrote:
>>>>      >
>>>>      >     JVMLS talks up at:
>>>>      > https://www.youtube.com/user/java
>>>>      >
>>>>      >
>>>>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>>>      >      > I'll be doing a talk on the path from Model 1 to Model
>>> 2
>>>>     (and a
>>>>      >     glimpse
>>>>      >      > of Model 3) at JVMLS next week.  Hope to see some of
>>> you
>>>>     there.
>>>>      >     Videos
>>>>      >      > should go up on the Java YouTube channel fairly quickly
>>>>     after the
>>>>      >      > conference.
>>>>      >      >
>>>>      >      > In the meantime ... I'll just note that we've had 50+
>>>>     messages on the
>>>>      >      > various "Model 2" threads and none of them started with
>>> "I
>>>>     tried
>>>>      >     it out
>>>>      >      > and..."
>>>>      >      >
>>>>      >      > So a reminder ... the most valuable input the community
>>>>     can give
>>>>      >     in this
>>>>      >      > process is to provide *actual experience reports*.
>>> That's
>>>>     the main
>>>>      >      > reason we make the significant investment in making the
>>>>     code and
>>>>      >     design
>>>>      >      > sketches available early -- so that people can actually
>>> try it
>>>>      >     out, and
>>>>      >      > help us see the holes that we might have missed.
>>>>      >      >
>>>>      >      >
>>>>      >
>>>>      > --
>>>>      > Pavol Marton
>>>> 
>>>> --
>>>> Pavol Marton
> 


From palo.marton at gmail.com  Thu Aug 20 08:01:22 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Thu, 20 Aug 2015 10:01:22 +0200
Subject: See you at JVMLS
In-Reply-To: <55D494DE.30906@gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com> <55D494DE.30906@gmail.com>
Message-ID: <CAPWSNUkPUz3u0jSHtNqgP0XRbuUsaQ5f-b7Bkyvq9r0S+20wzg@mail.gmail.com>

> If you recreate methods from Bar in Foo$any interface, then any change of
> such method in Bar (addition, signature change, ...) will be binary
> incompatible with separate compilation of Foo even though such method is
> not referenced anywhere in Foo (neither overridden nor called).
>

That's one option - create such "shadow" interfaces for superclasses.
(created by JVM on demand, so no problem with changes in super class after
compilation).

But I see also one more option: *Enhance JVM so that interface can extend
(exactly one) class* (and any number of interfaces). It may sound as an
"extreme" solution ... but somehow it makes sense to me. In current JVM
interfaces already extend one class, namely java.lang.Object. This is
"hardcoded" in JVM - you can e.g. call Object methods on interfaces, stack
slots with interface are treated as containing Object, etc... May be this
can be enhanced in a way that interface can have also different class as
its "superclass". Wild idea, but may be in the long term it is the best
solution...

From peter.levart at gmail.com  Thu Aug 20 09:32:30 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 20 Aug 2015 11:32:30 +0200
Subject: See you at JVMLS
In-Reply-To: <CAPWSNUkPUz3u0jSHtNqgP0XRbuUsaQ5f-b7Bkyvq9r0S+20wzg@mail.gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com> <55D494DE.30906@gmail.com>
	<CAPWSNUkPUz3u0jSHtNqgP0XRbuUsaQ5f-b7Bkyvq9r0S+20wzg@mail.gmail.com>
Message-ID: <55D59EAE.5080506@gmail.com>



On 08/20/2015 10:01 AM, Palo Marton wrote:
>
>     If you recreate methods from Bar in Foo$any interface, then any
>     change of such method in Bar (addition, signature change, ...)
>     will be binary incompatible with separate compilation of Foo even
>     though such method is not referenced anywhere in Foo (neither
>     overridden nor called).
>
>
> That's one option - create such "shadow" interfaces for superclasses. 
> (created by JVM on demand, so no problem with changes in super class 
> after compilation).
>
> But I see also one more option: _Enhance JVM so that interface can 
> extend (exactly one) class_ (and any number of interfaces). It may 
> sound as an "extreme" solution ... but somehow it makes sense to me. 
> In current JVM interfaces already extend one class, namely 
> java.lang.Object. This is "hardcoded" in JVM - you can e.g. call 
> Object methods on interfaces, stack slots with interface are treated 
> as containing Object, etc... May be this can be enhanced in a way that 
> interface can have also different class as its "superclass". Wild 
> idea, but may be in the long term it is the best solution...
>

Interfaces can implicitly extend class j.l.Object only because 
j.l.Object has no fields. Interfaces can't have fields. That's the 
restriction that allows multiple inheritance of interfaces.

Suppose you would have:

class C {
     int x;
}

interface I extends C {
}

class D {
     int x;
}

interface J extends D {
}

class E implements I, J {
}


E e = new E();

e.x = 123; // which 'x' ?

// and, more importantly, how could JIT optimize the following methods:

void m1(C c) {
     c.x = 123;
}

void m2(D d) {
     d.x = 234;
}

// when they could be called as:

m1(new E());
m1(new C());

m2(new E());
m2(new D());


Single inheritance of state is deeply baked into VM design as it allows 
the field of a class and all it's subclasses to be always located at the 
fixed offset from the beginning of the object.


But, theoretically, each class could have an implicit interface, which 
would be it's supertype and would contain all methods that the class 
implements and extend all interfaces that the class implements 
(including the implicit interface of it's superclass). It could be 
constructed on demand and "injected" into the class only in cases when 
needed during runtime. Such could be the Bar$any implicit interface of 
Bar class (from the example of this thread).

This would still not allow: Foo<any>.class.isAssignableFrom(Bar.class) 
to return true, but could solve Remi's concerns about package-private 
access to Bar methods via the Foo<any> interface.

But this interface injection seems too heavy weight to support just this 
simple aspect. Maybe the Foo<any> interface could just be "marked" with:

interface Foo$any implemented-by-subclasses-of Bar { ...

...meaning that VM would enforce this restriction (Foo$any could only be 
implemented by subclasses of Bar) and that Foo$any would implicitly 
"inherit" all methods from Bar. This would still not make Foo$any a 
subtype of Bar, but inherited methods would be owned by Bar and access 
checking would work correctly.

Regards, Peter


From palo.marton at gmail.com  Thu Aug 20 11:24:13 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Thu, 20 Aug 2015 13:24:13 +0200
Subject: See you at JVMLS
In-Reply-To: <55D59EAE.5080506@gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com> <55D494DE.30906@gmail.com>
	<CAPWSNUkPUz3u0jSHtNqgP0XRbuUsaQ5f-b7Bkyvq9r0S+20wzg@mail.gmail.com>
	<55D59EAE.5080506@gmail.com>
Message-ID: <CAPWSNU=rrJkp7w170nDcNLYxuZ0=AiUSyzrCuggpdHmeyD6-Bg@mail.gmail.com>

>
>
>
> class C {
>     int x;
> }
>
> interface I extends C {
> }
>
> class D {
>     int x;
> }
>
> interface J extends D {
> }
>
> class E implements I, J {
> }
>

This would be a compile time (or JVM link time) error as this interface
extends 2 classes.

From palo.marton at gmail.com  Thu Aug 20 11:47:36 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Thu, 20 Aug 2015 13:47:36 +0200
Subject: See you at JVMLS
In-Reply-To: <CAPWSNU=rrJkp7w170nDcNLYxuZ0=AiUSyzrCuggpdHmeyD6-Bg@mail.gmail.com>
References: <55C628CA.8070506@oracle.com> <55D364F6.2080407@oracle.com>
	<CAPWSNUnk-vsBa+xyMwmdVWOOf_xOUz8CV-NknKAtrMmu0hYQyA@mail.gmail.com>
	<55D3A607.2020101@oracle.com>
	<CAPWSNUk0EJ187jB=zSt+Sgao3OU4Dtsm9qaHaAH1QgGj4WnPjQ@mail.gmail.com>
	<55D3A951.7040105@oracle.com> <55D494DE.30906@gmail.com>
	<CAPWSNUkPUz3u0jSHtNqgP0XRbuUsaQ5f-b7Bkyvq9r0S+20wzg@mail.gmail.com>
	<55D59EAE.5080506@gmail.com>
	<CAPWSNU=rrJkp7w170nDcNLYxuZ0=AiUSyzrCuggpdHmeyD6-Bg@mail.gmail.com>
Message-ID: <CAPWSNUmPnLaoTROL8b-qP1fFRmZ5sdSJn1Ty4S6iCqoeDT5Lng@mail.gmail.com>

> This would be a compile time (or JVM link time) error as this interface
> extends 2 classes.
>

Sorry, I overlook that in your example E is a class (above reaction was for
interface E extends I,J). But anyway this will be also a compile time
error. Rule for classes could be: lass can implement an interface only if
it extends the same class as interface (or subclass of that class). So
these are OK
class E extends C implements I {}
class F extends D implements J {}

This is error:
class E implements I {}

Rules for interfaces would be that you can write any number of interfaces
and max 1 class in "extends", but in the end it must be resolved in a way
that interface extends exactly one class. If there is a class in "extends",
it is that class. If there are interfaces in "extends" that themselves
extend classes, then situation is checked for conflicts and the most
specific class is taken as "superclass" for the interface.

From smarter3 at gmail.com  Thu Aug 20 16:12:15 2015
From: smarter3 at gmail.com (Guillaume Martres)
Date: Thu, 20 Aug 2015 18:12:15 +0200
Subject: See you at JVMLS
In-Reply-To: <CAPWSNUmPnLaoTROL8b-qP1fFRmZ5sdSJn1Ty4S6iCqoeDT5Lng@mail.gmail.com>
References: <55C628CA.8070506@oracle.com>
	<CAPWSNU=rrJkp7w170nDcNLYxuZ0=AiUSyzrCuggpdHmeyD6-Bg@mail.gmail.com>
	<CAPWSNUmPnLaoTROL8b-qP1fFRmZ5sdSJn1Ty4S6iCqoeDT5Lng@mail.gmail.com>
Message-ID: <1903927.d8ZPMSroV6@marvin>

On Thursday 20 August 2015 13:47:36 Palo Marton wrote:
> > This would be a compile time (or JVM link time) error as this interface
> > extends 2 classes.
> 
> Sorry, I overlook that in your example E is a class (above reaction was for
> interface E extends I,J). But anyway this will be also a compile time
> error. Rule for classes could be: lass can implement an interface only if
> it extends the same class as interface (or subclass of that class). So
> these are OK
> class E extends C implements I {}
> class F extends D implements J {}
> 
> This is error:
> class E implements I {}
> 
> Rules for interfaces would be that you can write any number of interfaces
> and max 1 class in "extends", but in the end it must be resolved in a way
> that interface extends exactly one class. If there is a class in "extends",
> it is that class. If there are interfaces in "extends" that themselves
> extend classes, then situation is checked for conflicts and the most
> specific class is taken as "superclass" for the interface.

Keep going and you'll end up fully reinventing Scala traits ;)

From dl at cs.oswego.edu  Fri Aug 21 14:24:06 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 21 Aug 2015 10:24:06 -0400
Subject: jdk9 VarHandle and Fence methods
Message-ID: <55D73486.6050502@cs.oswego.edu>


For those of you who haven't been following this on the jmm-dev list
or follow-ups on concurrency-interest:

We are NOT planning a full JMM memory model update for jdk9 -- there
are still unresolved issues in revising the formal core model.
However, jdk9 will include APIs for VarHandles (a scaled-down version of
the "enhanced volatiles" JEP), that together with some other
support replaces the need to use of Unsafe to obtain these
effects and does so compatibly with C/C++11 atomics. To do this, we
must, until the next full JMM update, provide specs that are
clear to readers (at least those familiar with the underlying
concepts) but not formally tied to a base model, (Which limits
how much we can say in them.)

The tentative methods are pasted below and also at
   http://gee.cs.oswego.edu/dl/wwwtmp/Fodder.java
The javadocs currently do not include any examples helping to
explain why you would ever want to use any of these methods.

The actual VarHandle class will look a bit different because
it will rely on specializations of polymorphic signatures.
(Current versions can be found in the openjdk mercurial
"jdk9/sandbox" repo.) And the "Fences" method may end up
in a different java.lang.* utility class. We'd also retrofit
j.u.c.atomic.Atomic* classes to use compatible methods/names.

Comments welcome.

...

/**
  * Stand-in for spec purposes of jdk9 java.lang.invoke.VarHandle
  */
abstract class NotReallyVarHandle<T> {
     // Load

     /**
      * Returns the value, with memory semantics of reading a
      * non-volatile variable.
      *
      * @return the value
      */
     T getRelaxed(Object owner);

     /**
      * Returns the value, with memory semantics of reading a volatile
      * variable.
      *
      * @return the value
      */
     T getVolatile(Object owner);

     /**
      * Returns the value, and ensures that subsequent loads and stores
      * are not reordered before this access.
      *
      * @apiNote Ignoring the many semantic differences from C and
      * C++, this method has memory ordering effects compatible with
      * memory_order_acquire ordering.
      *
      * @return the value
      */
     T getAcquire(Object owner);

     /**
      * Returns the value, accessed in program order, but with no
      * assurance of memory ordering effects with respect to other
      * threads.
      *
      * @return the value
      */
     T getOpaque(Object owner);

     // Store

     /**
      * Sets the value, with memory semantics of setting a non-volatile
      * variable.
      *
      * @param val the new value
      */
     void setRelaxed(Object owner, T val);

     /**
      * Sets the value, with memory semantics of setting a volatile
      * variable.
      *
      * @apiNote Ignoring the many semantic differences from C and
      * C++, this method has memory ordering effects compatible with
      * memory_order_seq_cst.
      *
      * @param val the new value
      */
     void setVolatile(Object owner, T val);

     /**
      * Sets the value, and ensures that prior loads and stores are not
      * reordered after this access.
      *
      * @apiNote Ignoring the many semantic differences from C and
      * C++, this method has memory ordering effects compatible with
      * memory_order_release ordering.
      *
      * @param val the new value
      */
     void setRelease(Object owner, T val);

     /**
      * Sets the value, in program order, but with no assurance of
      * memory ordering effects with respect to other threads.
      *
      * @param val the new value
      */
     void setOpaque(Object owner, T val);

     // CAS

     /**
      * Atomically sets the value to the given updated value with the
      * memory semantics of setVolatile if the current value {@code ==}
      * the expected value, as accessed with the memory semantics of
      * getVolatile.
      *
      * @param expected the expected value
      * @param val the new value
      * @return {@code true} if successful. False return indicates that
      * the actual value was not equal to the expected value.
      */
     boolean compareAndSet(Object owner, T expected, T val);

     // Value-returning compare and exchange

     /**
      * Atomically sets the value to the given updated value with the
      * memory semantics of setVolatile if the current value {@code ==}
      * the expected value, as accessed with the memory semantics of
      * getVolatile.
      *
      * @param expected the expected value
      * @param val the new value
      * @return the current value, which will be the same as {@code val} if
      * successful.
      */
     T compareAndExchangeVolatile(Object owner, T expected, T val);

     /**
      * Atomically sets the value to the given updated value with the
      * memory semantics of setRelaxed if the current value {@code ==}
      * the expected value, as accessed with the memory semantics of
      * getAcquire.
      *
      * @param expected the expected value
      * @param val the new value
      * @return the current value, which will be the same as {@code val} if
      * successful.
      */
     T compareAndExchangeAcquire(Object owner, T expected, T val);

     /**
      * Atomically sets the value to the given updated value with the
      * memory semantics of setRelease if the current value {@code ==}
      * the expected value, as accessed with the memory samantics of
      * getRelease.
      *
      * @param expected the expected value
      * @param val the new value
      * @return the current value, which will be the same as {@code val} if
      * successful.
      */
     T compareAndExchangeRelease(Object owner, T expected, T val);

     // Weak (spurious failures allowed)

     /**
      * Possibly atomically sets the value to the given updated value
      * with the semantics of setRelaxed if the current value {@code
      * ==} the expected value, as as accessed with the memory
      * semantics of getRelaxed.  This operation may fail spuriously
      * (typically, due to memory contention) even if the current value
      * does match the expected value.
      *
      * @param expected the expected value
      * @param val the new value
      * @return {@code true} if successful
      */
     boolean weakCompareAndSetRelaxed(Object owner, T expected, T val);

     /**
      * Possibly atomically sets the value to the given updated value
      * with the memory semantics of setRelaxed if the current value
      * {@code ==} the expected value, as as accessed with the memory
      * semantics of getAcquire.  This operation may fail spuriously
      * (typically, due to memory contention) even if the current value
      * does match the expected value.
      *
      * @param expected the expected value
      * @param val the new value
      * @return {@code true} if successful
      */
     boolean weakCompareAndSetAcquire(Object owner, T expected, T val);

     /**
      * Possibly atomically sets the value to the given updated value
      * with the memory semantics of setRelease if the current value
      * {@code ==} the expected value, as as accessed with the memory
      * semantics of getRelaxed.  This operation may fail spuriously
      * (typically, due to memory contention) even if the current value
      * does match the expected value.
      *
      * @param expected the expected value
      * @param val the new value
      * @return {@code true} if successful
      */
     boolean weakCompareAndSetRelease(Object owner, T expected, T val);

     // special RMW

     /**
      * Atomically sets to the given value with the memory semantics of
      * setVolatile and returns the old value.
      *
      * @param newValue the new value
      * @return the previous value
      */
     T getAndSet(Object owner, T val);

     /**
      * Atomically adds the given value to the current value with the
      * memory semantics of setVolatile.
      *
      * @param delta the value to add
      * @return the previous value
      */
     T getAndAdd(Object owner, T delta);

     /**
      * Atomically adds the given value to the current value with the
      * memory semantics of setVolatile.
      *
      * @param delta the value to add
      * @return the current value
      */
     T addAndGet(Object owner, T delta);
}

/**
  * A set of methods providing fine-grained control of memory ordering.
  *
  * <p>The Java Language Specification permits operations to be
  * executed in orders different than are apparent in program source
  * code, subject to constraints mainly arising from the use of locks
  * and volatile fields. The methods of this class can also be used to
  * impose constraints. Their specifications are phrased in terms of
  * the lack of "reorderings" -- observable ordering effects that might
  * otherwise occur if the fence were not present.
  *
  * @apiNote More precise phrasing of these specifications may
  * accompany future updates of the Java Language Specification.
  */
public class Fences {

     /**
      * Ensures that loads and stores before the fence will not be
      * reordered with loads and stores after the fence.
      *
      * @apiNote Ignoring the many semantic differences from C and
      * C++, this method has memory ordering effects compatible with
      * atomic_thread_fence(memory_order_seq_cst)
      */
     public static void fullFence() {}

     /**
      * Ensures that loads before the fence will not be reordered with
      * loads and stores after the fence.
      *
      * @apiNote Ignoring the many semantic differences from C and
      * C++, this method has memory ordering effects compatible with
      * atomic_thread_fence(memory_order_acquire)
      */
     public static void acquireFence() {}

     /**
      * Ensures that loads and stores before the fence will not be
      * reordered with stores after the fence.
      *
      * @apiNote Ignoring the many semantic differences from C and
      * C++, this method has memory ordering effects compatible with
      * atomic_thread_fence(memory_order_release)
      */
     public static void releaseFence() {}

     /**
      * Ensures that loads before the fence will not be reordered with
      * loads after the fence.
      */
     public static void loadLoadFence() {}

     /**
      * Ensures that stores before the fence will not be reordered with
      * stores after the fence.
      */
     public static void storeStoreFence() {}

}

class java.lang.ref.Reference {
     // add:

     /**
      * Ensures that the object referenced by the given reference
      * remains <em>strongly reachable</em> (as defined in the {@link
      * java.lang.ref} package documentation), regardless of any prior
      * actions of the program that might otherwise cause the object to
      * become unreachable; thus, the referenced object is not
      * reclaimable by garbage collection at least until after the
      * invocation of this method. Invocation of this method does not
      * itself initiate garbage collection or finalization.
      *
      * @param ref the reference. If null, this method has no effect.
      */
     public static void reachabilityFence(Object ref) {}

}

From palo.marton at gmail.com  Fri Aug 21 14:42:07 2015
From: palo.marton at gmail.com (Palo Marton)
Date: Fri, 21 Aug 2015 16:42:07 +0200
Subject: See you at JVMLS
In-Reply-To: <1903927.d8ZPMSroV6@marvin>
References: <55C628CA.8070506@oracle.com>
	<CAPWSNU=rrJkp7w170nDcNLYxuZ0=AiUSyzrCuggpdHmeyD6-Bg@mail.gmail.com>
	<CAPWSNUmPnLaoTROL8b-qP1fFRmZ5sdSJn1Ty4S6iCqoeDT5Lng@mail.gmail.com>
	<1903927.d8ZPMSroV6@marvin>
Message-ID: <CAPWSNU=7LPCwxph99yd2WD=7z+eLNXY4E2ypvFxraTiYVGVNOQ@mail.gmail.com>

> Keep going and you'll end up fully reinventing Scala traits ;)
>

I'm not familiar with Scala... seems to be something very similar ;-)

But anyway - implementing "traits" in JVM is not a part of Valhalla, but
may be they will get into Java somewhere in the future and that's a good
reason to choose conservative approach to Foo$any <-> Bar problem that will
leave this option open:

1) leave the low level relation between Foo$any and Bar unspecified (=its
up to each JVM how it implements it)
2) leave isAssignableFrom unspecified
3) compile f.barMethod()  as ((Bar)f).barMethod()

And in the first Valhala JVM implement it this way:

4) no low level relation between Foo$any and Bar
5) Bar methods will not be recreated in Foo$any and no "shadow" interface
created for Bar (there is no need for that as Bar method calls are compiled
with cast to Bar)
6) isAssignableFrom will return false (but it is unspecified, so some
future JVM may return true)

From gil at azulsystems.com  Fri Aug 21 14:50:27 2015
From: gil at azulsystems.com (Gil Tene)
Date: Fri, 21 Aug 2015 14:50:27 +0000
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <55D73486.6050502@cs.oswego.edu>
References: <55D73486.6050502@cs.oswego.edu>
Message-ID: <437E960B-EE9D-40FF-BA9E-A7CE761CDC86@azulsystems.com>

Doug,

For clarity (and because I expect lots of other to ask this in the future):

- What is the relationship between the below NotReallyVarHandle.setOpaque(), the current Atomic*.lazySet(), and the below Fences.storeStoreFence() ?

Specifically:

- How should one use Fences.storeStoreFence() (and/or other methods) to achieve the equivalent of an Atomic*.lazyset()?

- Is NotReallyVarHandle.setOpaque() more relaxed than a lazySet()? Or is it similar?

- How does NotReallyVarHandle.setOpaque() differ from NotReallyVarHandle.setRelaxed() (I would assume that setRelaxed() still has to maintain program order for the thread that executes it).

BTW, my understanding of the current lazySet() implementation is that it guarantees a store-store fence preceding the lazy store (but does not guarantee one after the operation). In implementation (e.g. in HotSpot) it appears to provide a store-store both before and after the operation (but I don't thin that this can be assumed to be guaranteed).

? Gil.

> On Aug 21, 2015, at 7:24 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> 
> For those of you who haven't been following this on the jmm-dev list
> or follow-ups on concurrency-interest:
> 
> We are NOT planning a full JMM memory model update for jdk9 -- there
> are still unresolved issues in revising the formal core model.
> However, jdk9 will include APIs for VarHandles (a scaled-down version of
> the "enhanced volatiles" JEP), that together with some other
> support replaces the need to use of Unsafe to obtain these
> effects and does so compatibly with C/C++11 atomics. To do this, we
> must, until the next full JMM update, provide specs that are
> clear to readers (at least those familiar with the underlying
> concepts) but not formally tied to a base model, (Which limits
> how much we can say in them.)
> 
> The tentative methods are pasted below and also at
>  http://gee.cs.oswego.edu/dl/wwwtmp/Fodder.java
> The javadocs currently do not include any examples helping to
> explain why you would ever want to use any of these methods.
> 
> The actual VarHandle class will look a bit different because
> it will rely on specializations of polymorphic signatures.
> (Current versions can be found in the openjdk mercurial
> "jdk9/sandbox" repo.) And the "Fences" method may end up
> in a different java.lang.* utility class. We'd also retrofit
> j.u.c.atomic.Atomic* classes to use compatible methods/names.
> 
> Comments welcome.
> 
> ...
> 
> /**
> * Stand-in for spec purposes of jdk9 java.lang.invoke.VarHandle
> */
> abstract class NotReallyVarHandle<T> {
>    // Load
> 
>    /**
>     * Returns the value, with memory semantics of reading a
>     * non-volatile variable.
>     *
>     * @return the value
>     */
>    T getRelaxed(Object owner);
> 
>    /**
>     * Returns the value, with memory semantics of reading a volatile
>     * variable.
>     *
>     * @return the value
>     */
>    T getVolatile(Object owner);
> 
>    /**
>     * Returns the value, and ensures that subsequent loads and stores
>     * are not reordered before this access.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * memory_order_acquire ordering.
>     *
>     * @return the value
>     */
>    T getAcquire(Object owner);
> 
>    /**
>     * Returns the value, accessed in program order, but with no
>     * assurance of memory ordering effects with respect to other
>     * threads.
>     *
>     * @return the value
>     */
>    T getOpaque(Object owner);
> 
>    // Store
> 
>    /**
>     * Sets the value, with memory semantics of setting a non-volatile
>     * variable.
>     *
>     * @param val the new value
>     */
>    void setRelaxed(Object owner, T val);
> 
>    /**
>     * Sets the value, with memory semantics of setting a volatile
>     * variable.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * memory_order_seq_cst.
>     *
>     * @param val the new value
>     */
>    void setVolatile(Object owner, T val);
> 
>    /**
>     * Sets the value, and ensures that prior loads and stores are not
>     * reordered after this access.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * memory_order_release ordering.
>     *
>     * @param val the new value
>     */
>    void setRelease(Object owner, T val);
> 
>    /**
>     * Sets the value, in program order, but with no assurance of
>     * memory ordering effects with respect to other threads.
>     *
>     * @param val the new value
>     */
>    void setOpaque(Object owner, T val);
> 
>    // CAS
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setVolatile if the current value {@code ==}
>     * the expected value, as accessed with the memory semantics of
>     * getVolatile.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful. False return indicates that
>     * the actual value was not equal to the expected value.
>     */
>    boolean compareAndSet(Object owner, T expected, T val);
> 
>    // Value-returning compare and exchange
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setVolatile if the current value {@code ==}
>     * the expected value, as accessed with the memory semantics of
>     * getVolatile.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return the current value, which will be the same as {@code val} if
>     * successful.
>     */
>    T compareAndExchangeVolatile(Object owner, T expected, T val);
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setRelaxed if the current value {@code ==}
>     * the expected value, as accessed with the memory semantics of
>     * getAcquire.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return the current value, which will be the same as {@code val} if
>     * successful.
>     */
>    T compareAndExchangeAcquire(Object owner, T expected, T val);
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setRelease if the current value {@code ==}
>     * the expected value, as accessed with the memory samantics of
>     * getRelease.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return the current value, which will be the same as {@code val} if
>     * successful.
>     */
>    T compareAndExchangeRelease(Object owner, T expected, T val);
> 
>    // Weak (spurious failures allowed)
> 
>    /**
>     * Possibly atomically sets the value to the given updated value
>     * with the semantics of setRelaxed if the current value {@code
>     * ==} the expected value, as as accessed with the memory
>     * semantics of getRelaxed.  This operation may fail spuriously
>     * (typically, due to memory contention) even if the current value
>     * does match the expected value.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful
>     */
>    boolean weakCompareAndSetRelaxed(Object owner, T expected, T val);
> 
>    /**
>     * Possibly atomically sets the value to the given updated value
>     * with the memory semantics of setRelaxed if the current value
>     * {@code ==} the expected value, as as accessed with the memory
>     * semantics of getAcquire.  This operation may fail spuriously
>     * (typically, due to memory contention) even if the current value
>     * does match the expected value.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful
>     */
>    boolean weakCompareAndSetAcquire(Object owner, T expected, T val);
> 
>    /**
>     * Possibly atomically sets the value to the given updated value
>     * with the memory semantics of setRelease if the current value
>     * {@code ==} the expected value, as as accessed with the memory
>     * semantics of getRelaxed.  This operation may fail spuriously
>     * (typically, due to memory contention) even if the current value
>     * does match the expected value.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful
>     */
>    boolean weakCompareAndSetRelease(Object owner, T expected, T val);
> 
>    // special RMW
> 
>    /**
>     * Atomically sets to the given value with the memory semantics of
>     * setVolatile and returns the old value.
>     *
>     * @param newValue the new value
>     * @return the previous value
>     */
>    T getAndSet(Object owner, T val);
> 
>    /**
>     * Atomically adds the given value to the current value with the
>     * memory semantics of setVolatile.
>     *
>     * @param delta the value to add
>     * @return the previous value
>     */
>    T getAndAdd(Object owner, T delta);
> 
>    /**
>     * Atomically adds the given value to the current value with the
>     * memory semantics of setVolatile.
>     *
>     * @param delta the value to add
>     * @return the current value
>     */
>    T addAndGet(Object owner, T delta);
> }
> 
> /**
> * A set of methods providing fine-grained control of memory ordering.
> *
> * <p>The Java Language Specification permits operations to be
> * executed in orders different than are apparent in program source
> * code, subject to constraints mainly arising from the use of locks
> * and volatile fields. The methods of this class can also be used to
> * impose constraints. Their specifications are phrased in terms of
> * the lack of "reorderings" -- observable ordering effects that might
> * otherwise occur if the fence were not present.
> *
> * @apiNote More precise phrasing of these specifications may
> * accompany future updates of the Java Language Specification.
> */
> public class Fences {
> 
>    /**
>     * Ensures that loads and stores before the fence will not be
>     * reordered with loads and stores after the fence.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * atomic_thread_fence(memory_order_seq_cst)
>     */
>    public static void fullFence() {}
> 
>    /**
>     * Ensures that loads before the fence will not be reordered with
>     * loads and stores after the fence.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * atomic_thread_fence(memory_order_acquire)
>     */
>    public static void acquireFence() {}
> 
>    /**
>     * Ensures that loads and stores before the fence will not be
>     * reordered with stores after the fence.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * atomic_thread_fence(memory_order_release)
>     */
>    public static void releaseFence() {}
> 
>    /**
>     * Ensures that loads before the fence will not be reordered with
>     * loads after the fence.
>     */
>    public static void loadLoadFence() {}
> 
>    /**
>     * Ensures that stores before the fence will not be reordered with
>     * stores after the fence.
>     */
>    public static void storeStoreFence() {}
> 
> }
> 
> class java.lang.ref.Reference {
>    // add:
> 
>    /**
>     * Ensures that the object referenced by the given reference
>     * remains <em>strongly reachable</em> (as defined in the {@link
>     * java.lang.ref} package documentation), regardless of any prior
>     * actions of the program that might otherwise cause the object to
>     * become unreachable; thus, the referenced object is not
>     * reclaimable by garbage collection at least until after the
>     * invocation of this method. Invocation of this method does not
>     * itself initiate garbage collection or finalization.
>     *
>     * @param ref the reference. If null, this method has no effect.
>     */
>    public static void reachabilityFence(Object ref) {}
> 
> }


From dl at cs.oswego.edu  Fri Aug 21 16:39:46 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 21 Aug 2015 12:39:46 -0400
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <437E960B-EE9D-40FF-BA9E-A7CE761CDC86@azulsystems.com>
References: <55D73486.6050502@cs.oswego.edu>
	<437E960B-EE9D-40FF-BA9E-A7CE761CDC86@azulsystems.com>
Message-ID: <55D75452.5050504@cs.oswego.edu>

On 08/21/2015 10:50 AM, Gil Tene wrote:

> Specifically:
>
> - How should one use Fences.storeStoreFence() (and/or other methods) to
> achieve the equivalent of an Atomic*.lazyset()?

First: lazySet was among the worst names ever, although the internal
name putOrderedX comes close. So this is more confusing than it should be.

AtomicX.lazySet will become a synonym for setRelease, and compatible
with C/C++11 memory_order_release stores. You can also
get essentially the same effect using a preceding releaseFence.
In turn releaseFence maps into the current hotspot MemBarRelease,
accessible (for now) via Unsafe.storeFence. It is stronger than
hotspot MemBarStoreStore (that will also be exported) because
releaseFence includes a LoadStore. You almost always want
releaseFence. The range of sane applicability of storeStoreFence
is small, and it might not even be included except that there are
processors (including ARM) for which it is generally cheaper
when it applies.

> - Is NotReallyVarHandle.setOpaque() more relaxed than a lazySet()? Or is it
> similar?

The unloved-but-necessary method setOpaque is setRelaxed with what
amounts to a compiler directive saying that the write must actually
occur even if other JMM rules would allow it to be optimized away.
Usage should be rare. Think IO.

> BTW, my understanding of the current lazySet() implementation is that it
> guarantees a store-store fence preceding the lazy store (but does not
> guarantee one after the operation). In implementation (e.g. in HotSpot) it
> appears to provide a store-store both before and after the operation (but I
> don't thin that this can be assumed to be guaranteed).

setRelease/lazySet/putOrderedX does not require a trailing fence.
Compilers may impose an internal reordering fence for internal reasons.

-Doug




From gil at azulsystems.com  Fri Aug 21 17:58:10 2015
From: gil at azulsystems.com (Gil Tene)
Date: Fri, 21 Aug 2015 17:58:10 +0000
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <55D75452.5050504@cs.oswego.edu>
References: <55D73486.6050502@cs.oswego.edu>
	<437E960B-EE9D-40FF-BA9E-A7CE761CDC86@azulsystems.com>
	<55D75452.5050504@cs.oswego.edu>
Message-ID: <1C658A2D-F5B0-4231-8191-ACE28B82F107@azulsystems.com>


> On Aug 21, 2015, at 9:39 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 08/21/2015 10:50 AM, Gil Tene wrote:
> ...
>> - Is NotReallyVarHandle.setOpaque() more relaxed than a lazySet()? Or is it
>> similar?
> 
> The unloved-but-necessary method setOpaque is setRelaxed with what
> amounts to a compiler directive saying that the write must actually
> occur even if other JMM rules would allow it to be optimized away.
> Usage should be rare. Think IO.

Ok, that makes more sense (as written above).

I think the comment needs to make this semantic meaning clear. The current one does not, leading to obvious questions.

The IO example is a good one. It is probably more tricky to word when it comes to non-IO realms, as "write [to memory] must actually occur" is hard to map to how various memory hierarchies are managed. Perhaps identifying it as a write to coherent memory being required would work. E.g. a write to globally coherent L1 data cache will probably qualify for what the operation is intended to do, but a write to a non-coherent structure (a CPU register, a non-coherent L1 cache, a local memory in a loosely coupled non-fully-coherent memory system) probably does not qualify unless a following coherency-assusring operation makes the data coherently visible (example coherency-creating operations can be: a write of the register to memory, a flush of dirty lines in a non-coherent cache, a cross-network data update in a loosely coupled message-based distributed system).

? Gil.


From brian.goetz at oracle.com  Fri Aug 21 21:23:48 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 21 Aug 2015 21:23:48 +0000
Subject: hg: valhalla/valhalla/jdk: Initial implementation of metacircular
	interpreter
Message-ID: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>

Changeset: f0a19269be37
Author:    briangoetz
Date:      2015-08-21 17:23 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f0a19269be37

Initial implementation of metacircular interpreter

+ interpreter/src/valhalla/interpreter/Frame.java
+ interpreter/src/valhalla/interpreter/Interpreter.java
+ interpreter/src/valhalla/interpreter/InterpreterError.java
+ interpreter/src/valhalla/interpreter/OpcodeHandler.java
+ interpreter/test/valhalla/interpreter/FrameTest.java
+ interpreter/test/valhalla/interpreter/InterpreterTest.java
! src/java.base/share/classes/java/anyutil/Spliterator.java
! src/java.base/share/classes/java/anyutil/stream/IntStream.java
! src/java.base/share/classes/java/anyutil/stream/Streams.java


From dl at cs.oswego.edu  Fri Aug 21 23:21:17 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 21 Aug 2015 19:21:17 -0400
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <1C658A2D-F5B0-4231-8191-ACE28B82F107@azulsystems.com>
References: <55D73486.6050502@cs.oswego.edu>
	<437E960B-EE9D-40FF-BA9E-A7CE761CDC86@azulsystems.com>
	<55D75452.5050504@cs.oswego.edu>
	<1C658A2D-F5B0-4231-8191-ACE28B82F107@azulsystems.com>
Message-ID: <55D7B26D.2060504@cs.oswego.edu>

On 08/21/2015 01:58 PM, Gil Tene wrote:

>> On 08/21/2015 10:50 AM, Gil Tene wrote: ...
>>> - Is NotReallyVarHandle.setOpaque() more relaxed than a lazySet()? Or is
>>> it similar?
>>
>> The unloved-but-necessary method setOpaque is setRelaxed with what amounts
>> to a compiler directive saying that the write must actually occur even if
>> other JMM rules would allow it to be optimized away. Usage should be rare.
>> Think IO.
>
> Ok, that makes more sense (as written above).
>
> I think the comment needs to make this semantic meaning clear.

Right. Doing so is challenging within the confines of not accidentally
revising the JMM inside the javadoc.

> The current one does not, leading to obvious questions.
>
> The IO example is a good one. It is probably more tricky to word when it
> comes to non-IO realms, as "write [to memory] must actually occur"

Yes. Most likely a formal spec would be in terms of not indefinitely
postponing reads/writes. Which is itself problematic because it
ultimately requires progress, which we try to avoid (over)specifying.

-Doug

From gil at azulsystems.com  Sat Aug 22 17:54:18 2015
From: gil at azulsystems.com (Gil Tene)
Date: Sat, 22 Aug 2015 17:54:18 +0000
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <55D73486.6050502@cs.oswego.edu>
References: <55D73486.6050502@cs.oswego.edu>
Message-ID: <2554DA3C-2F60-4B30-82CB-3BDDE4B3FA47@azulsystems.com>

Its' great to see storeStoreFence() and loadLoadFence() in the Fences class.

For completeness, I would really like to see loadStoreFence() and storeLoadFence() there as well. I realize that they are implicitly available via the combination fences (acquire, release, and full), but it is "strange" to have just the first two without providing the complete set. There are certainly cases where all you need is a StoreLoad or a LoadStore, and forcing the other unneeded fences in combination reduces potential compiler optimizations on that code.

? Gil.

> On Aug 21, 2015, at 7:24 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> 
> For those of you who haven't been following this on the jmm-dev list
> or follow-ups on concurrency-interest:
> 
> We are NOT planning a full JMM memory model update for jdk9 -- there
> are still unresolved issues in revising the formal core model.
> However, jdk9 will include APIs for VarHandles (a scaled-down version of
> the "enhanced volatiles" JEP), that together with some other
> support replaces the need to use of Unsafe to obtain these
> effects and does so compatibly with C/C++11 atomics. To do this, we
> must, until the next full JMM update, provide specs that are
> clear to readers (at least those familiar with the underlying
> concepts) but not formally tied to a base model, (Which limits
> how much we can say in them.)
> 
> The tentative methods are pasted below and also at
>  http://gee.cs.oswego.edu/dl/wwwtmp/Fodder.java
> The javadocs currently do not include any examples helping to
> explain why you would ever want to use any of these methods.
> 
> The actual VarHandle class will look a bit different because
> it will rely on specializations of polymorphic signatures.
> (Current versions can be found in the openjdk mercurial
> "jdk9/sandbox" repo.) And the "Fences" method may end up
> in a different java.lang.* utility class. We'd also retrofit
> j.u.c.atomic.Atomic* classes to use compatible methods/names.
> 
> Comments welcome.
> 
> ...
> 
> /**
> * Stand-in for spec purposes of jdk9 java.lang.invoke.VarHandle
> */
> abstract class NotReallyVarHandle<T> {
>    // Load
> 
>    /**
>     * Returns the value, with memory semantics of reading a
>     * non-volatile variable.
>     *
>     * @return the value
>     */
>    T getRelaxed(Object owner);
> 
>    /**
>     * Returns the value, with memory semantics of reading a volatile
>     * variable.
>     *
>     * @return the value
>     */
>    T getVolatile(Object owner);
> 
>    /**
>     * Returns the value, and ensures that subsequent loads and stores
>     * are not reordered before this access.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * memory_order_acquire ordering.
>     *
>     * @return the value
>     */
>    T getAcquire(Object owner);
> 
>    /**
>     * Returns the value, accessed in program order, but with no
>     * assurance of memory ordering effects with respect to other
>     * threads.
>     *
>     * @return the value
>     */
>    T getOpaque(Object owner);
> 
>    // Store
> 
>    /**
>     * Sets the value, with memory semantics of setting a non-volatile
>     * variable.
>     *
>     * @param val the new value
>     */
>    void setRelaxed(Object owner, T val);
> 
>    /**
>     * Sets the value, with memory semantics of setting a volatile
>     * variable.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * memory_order_seq_cst.
>     *
>     * @param val the new value
>     */
>    void setVolatile(Object owner, T val);
> 
>    /**
>     * Sets the value, and ensures that prior loads and stores are not
>     * reordered after this access.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * memory_order_release ordering.
>     *
>     * @param val the new value
>     */
>    void setRelease(Object owner, T val);
> 
>    /**
>     * Sets the value, in program order, but with no assurance of
>     * memory ordering effects with respect to other threads.
>     *
>     * @param val the new value
>     */
>    void setOpaque(Object owner, T val);
> 
>    // CAS
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setVolatile if the current value {@code ==}
>     * the expected value, as accessed with the memory semantics of
>     * getVolatile.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful. False return indicates that
>     * the actual value was not equal to the expected value.
>     */
>    boolean compareAndSet(Object owner, T expected, T val);
> 
>    // Value-returning compare and exchange
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setVolatile if the current value {@code ==}
>     * the expected value, as accessed with the memory semantics of
>     * getVolatile.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return the current value, which will be the same as {@code val} if
>     * successful.
>     */
>    T compareAndExchangeVolatile(Object owner, T expected, T val);
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setRelaxed if the current value {@code ==}
>     * the expected value, as accessed with the memory semantics of
>     * getAcquire.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return the current value, which will be the same as {@code val} if
>     * successful.
>     */
>    T compareAndExchangeAcquire(Object owner, T expected, T val);
> 
>    /**
>     * Atomically sets the value to the given updated value with the
>     * memory semantics of setRelease if the current value {@code ==}
>     * the expected value, as accessed with the memory samantics of
>     * getRelease.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return the current value, which will be the same as {@code val} if
>     * successful.
>     */
>    T compareAndExchangeRelease(Object owner, T expected, T val);
> 
>    // Weak (spurious failures allowed)
> 
>    /**
>     * Possibly atomically sets the value to the given updated value
>     * with the semantics of setRelaxed if the current value {@code
>     * ==} the expected value, as as accessed with the memory
>     * semantics of getRelaxed.  This operation may fail spuriously
>     * (typically, due to memory contention) even if the current value
>     * does match the expected value.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful
>     */
>    boolean weakCompareAndSetRelaxed(Object owner, T expected, T val);
> 
>    /**
>     * Possibly atomically sets the value to the given updated value
>     * with the memory semantics of setRelaxed if the current value
>     * {@code ==} the expected value, as as accessed with the memory
>     * semantics of getAcquire.  This operation may fail spuriously
>     * (typically, due to memory contention) even if the current value
>     * does match the expected value.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful
>     */
>    boolean weakCompareAndSetAcquire(Object owner, T expected, T val);
> 
>    /**
>     * Possibly atomically sets the value to the given updated value
>     * with the memory semantics of setRelease if the current value
>     * {@code ==} the expected value, as as accessed with the memory
>     * semantics of getRelaxed.  This operation may fail spuriously
>     * (typically, due to memory contention) even if the current value
>     * does match the expected value.
>     *
>     * @param expected the expected value
>     * @param val the new value
>     * @return {@code true} if successful
>     */
>    boolean weakCompareAndSetRelease(Object owner, T expected, T val);
> 
>    // special RMW
> 
>    /**
>     * Atomically sets to the given value with the memory semantics of
>     * setVolatile and returns the old value.
>     *
>     * @param newValue the new value
>     * @return the previous value
>     */
>    T getAndSet(Object owner, T val);
> 
>    /**
>     * Atomically adds the given value to the current value with the
>     * memory semantics of setVolatile.
>     *
>     * @param delta the value to add
>     * @return the previous value
>     */
>    T getAndAdd(Object owner, T delta);
> 
>    /**
>     * Atomically adds the given value to the current value with the
>     * memory semantics of setVolatile.
>     *
>     * @param delta the value to add
>     * @return the current value
>     */
>    T addAndGet(Object owner, T delta);
> }
> 
> /**
> * A set of methods providing fine-grained control of memory ordering.
> *
> * <p>The Java Language Specification permits operations to be
> * executed in orders different than are apparent in program source
> * code, subject to constraints mainly arising from the use of locks
> * and volatile fields. The methods of this class can also be used to
> * impose constraints. Their specifications are phrased in terms of
> * the lack of "reorderings" -- observable ordering effects that might
> * otherwise occur if the fence were not present.
> *
> * @apiNote More precise phrasing of these specifications may
> * accompany future updates of the Java Language Specification.
> */
> public class Fences {
> 
>    /**
>     * Ensures that loads and stores before the fence will not be
>     * reordered with loads and stores after the fence.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * atomic_thread_fence(memory_order_seq_cst)
>     */
>    public static void fullFence() {}
> 
>    /**
>     * Ensures that loads before the fence will not be reordered with
>     * loads and stores after the fence.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * atomic_thread_fence(memory_order_acquire)
>     */
>    public static void acquireFence() {}
> 
>    /**
>     * Ensures that loads and stores before the fence will not be
>     * reordered with stores after the fence.
>     *
>     * @apiNote Ignoring the many semantic differences from C and
>     * C++, this method has memory ordering effects compatible with
>     * atomic_thread_fence(memory_order_release)
>     */
>    public static void releaseFence() {}
> 
>    /**
>     * Ensures that loads before the fence will not be reordered with
>     * loads after the fence.
>     */
>    public static void loadLoadFence() {}
> 
>    /**
>     * Ensures that stores before the fence will not be reordered with
>     * stores after the fence.
>     */
>    public static void storeStoreFence() {}
> 
> }
> 
> class java.lang.ref.Reference {
>    // add:
> 
>    /**
>     * Ensures that the object referenced by the given reference
>     * remains <em>strongly reachable</em> (as defined in the {@link
>     * java.lang.ref} package documentation), regardless of any prior
>     * actions of the program that might otherwise cause the object to
>     * become unreachable; thus, the referenced object is not
>     * reclaimable by garbage collection at least until after the
>     * invocation of this method. Invocation of this method does not
>     * itself initiate garbage collection or finalization.
>     *
>     * @param ref the reference. If null, this method has no effect.
>     */
>    public static void reachabilityFence(Object ref) {}
> 
> }


From vitalyd at gmail.com  Sat Aug 22 18:24:15 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Sat, 22 Aug 2015 14:24:15 -0400
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <2554DA3C-2F60-4B30-82CB-3BDDE4B3FA47@azulsystems.com>
References: <55D73486.6050502@cs.oswego.edu>
	<2554DA3C-2F60-4B30-82CB-3BDDE4B3FA47@azulsystems.com>
Message-ID: <CAHjP37HsC1j8xq2F6_8+ze8puowDcMVDuYDDGr9KPGYL8vj3cw@mail.gmail.com>

+1.  StoreLoad is probably not that interesting on its own since that's a
cpu fence even on TSO but LoadStore could be nice as it can be a CPU nop on
some archs.  But yeah, for completeness, it'd be good to have all 4 combos
available.

sent from my phone
On Aug 22, 2015 1:54 PM, "Gil Tene" <gil at azulsystems.com> wrote:

> Its' great to see storeStoreFence() and loadLoadFence() in the Fences
> class.
>
> For completeness, I would really like to see loadStoreFence() and
> storeLoadFence() there as well. I realize that they are implicitly
> available via the combination fences (acquire, release, and full), but it
> is "strange" to have just the first two without providing the complete set.
> There are certainly cases where all you need is a StoreLoad or a LoadStore,
> and forcing the other unneeded fences in combination reduces potential
> compiler optimizations on that code.
>
> ? Gil.
>
> > On Aug 21, 2015, at 7:24 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> >
> >
> > For those of you who haven't been following this on the jmm-dev list
> > or follow-ups on concurrency-interest:
> >
> > We are NOT planning a full JMM memory model update for jdk9 -- there
> > are still unresolved issues in revising the formal core model.
> > However, jdk9 will include APIs for VarHandles (a scaled-down version of
> > the "enhanced volatiles" JEP), that together with some other
> > support replaces the need to use of Unsafe to obtain these
> > effects and does so compatibly with C/C++11 atomics. To do this, we
> > must, until the next full JMM update, provide specs that are
> > clear to readers (at least those familiar with the underlying
> > concepts) but not formally tied to a base model, (Which limits
> > how much we can say in them.)
> >
> > The tentative methods are pasted below and also at
> >  http://gee.cs.oswego.edu/dl/wwwtmp/Fodder.java
> > The javadocs currently do not include any examples helping to
> > explain why you would ever want to use any of these methods.
> >
> > The actual VarHandle class will look a bit different because
> > it will rely on specializations of polymorphic signatures.
> > (Current versions can be found in the openjdk mercurial
> > "jdk9/sandbox" repo.) And the "Fences" method may end up
> > in a different java.lang.* utility class. We'd also retrofit
> > j.u.c.atomic.Atomic* classes to use compatible methods/names.
> >
> > Comments welcome.
> >
> > ...
> >
> > /**
> > * Stand-in for spec purposes of jdk9 java.lang.invoke.VarHandle
> > */
> > abstract class NotReallyVarHandle<T> {
> >    // Load
> >
> >    /**
> >     * Returns the value, with memory semantics of reading a
> >     * non-volatile variable.
> >     *
> >     * @return the value
> >     */
> >    T getRelaxed(Object owner);
> >
> >    /**
> >     * Returns the value, with memory semantics of reading a volatile
> >     * variable.
> >     *
> >     * @return the value
> >     */
> >    T getVolatile(Object owner);
> >
> >    /**
> >     * Returns the value, and ensures that subsequent loads and stores
> >     * are not reordered before this access.
> >     *
> >     * @apiNote Ignoring the many semantic differences from C and
> >     * C++, this method has memory ordering effects compatible with
> >     * memory_order_acquire ordering.
> >     *
> >     * @return the value
> >     */
> >    T getAcquire(Object owner);
> >
> >    /**
> >     * Returns the value, accessed in program order, but with no
> >     * assurance of memory ordering effects with respect to other
> >     * threads.
> >     *
> >     * @return the value
> >     */
> >    T getOpaque(Object owner);
> >
> >    // Store
> >
> >    /**
> >     * Sets the value, with memory semantics of setting a non-volatile
> >     * variable.
> >     *
> >     * @param val the new value
> >     */
> >    void setRelaxed(Object owner, T val);
> >
> >    /**
> >     * Sets the value, with memory semantics of setting a volatile
> >     * variable.
> >     *
> >     * @apiNote Ignoring the many semantic differences from C and
> >     * C++, this method has memory ordering effects compatible with
> >     * memory_order_seq_cst.
> >     *
> >     * @param val the new value
> >     */
> >    void setVolatile(Object owner, T val);
> >
> >    /**
> >     * Sets the value, and ensures that prior loads and stores are not
> >     * reordered after this access.
> >     *
> >     * @apiNote Ignoring the many semantic differences from C and
> >     * C++, this method has memory ordering effects compatible with
> >     * memory_order_release ordering.
> >     *
> >     * @param val the new value
> >     */
> >    void setRelease(Object owner, T val);
> >
> >    /**
> >     * Sets the value, in program order, but with no assurance of
> >     * memory ordering effects with respect to other threads.
> >     *
> >     * @param val the new value
> >     */
> >    void setOpaque(Object owner, T val);
> >
> >    // CAS
> >
> >    /**
> >     * Atomically sets the value to the given updated value with the
> >     * memory semantics of setVolatile if the current value {@code ==}
> >     * the expected value, as accessed with the memory semantics of
> >     * getVolatile.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return {@code true} if successful. False return indicates that
> >     * the actual value was not equal to the expected value.
> >     */
> >    boolean compareAndSet(Object owner, T expected, T val);
> >
> >    // Value-returning compare and exchange
> >
> >    /**
> >     * Atomically sets the value to the given updated value with the
> >     * memory semantics of setVolatile if the current value {@code ==}
> >     * the expected value, as accessed with the memory semantics of
> >     * getVolatile.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return the current value, which will be the same as {@code val} if
> >     * successful.
> >     */
> >    T compareAndExchangeVolatile(Object owner, T expected, T val);
> >
> >    /**
> >     * Atomically sets the value to the given updated value with the
> >     * memory semantics of setRelaxed if the current value {@code ==}
> >     * the expected value, as accessed with the memory semantics of
> >     * getAcquire.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return the current value, which will be the same as {@code val} if
> >     * successful.
> >     */
> >    T compareAndExchangeAcquire(Object owner, T expected, T val);
> >
> >    /**
> >     * Atomically sets the value to the given updated value with the
> >     * memory semantics of setRelease if the current value {@code ==}
> >     * the expected value, as accessed with the memory samantics of
> >     * getRelease.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return the current value, which will be the same as {@code val} if
> >     * successful.
> >     */
> >    T compareAndExchangeRelease(Object owner, T expected, T val);
> >
> >    // Weak (spurious failures allowed)
> >
> >    /**
> >     * Possibly atomically sets the value to the given updated value
> >     * with the semantics of setRelaxed if the current value {@code
> >     * ==} the expected value, as as accessed with the memory
> >     * semantics of getRelaxed.  This operation may fail spuriously
> >     * (typically, due to memory contention) even if the current value
> >     * does match the expected value.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return {@code true} if successful
> >     */
> >    boolean weakCompareAndSetRelaxed(Object owner, T expected, T val);
> >
> >    /**
> >     * Possibly atomically sets the value to the given updated value
> >     * with the memory semantics of setRelaxed if the current value
> >     * {@code ==} the expected value, as as accessed with the memory
> >     * semantics of getAcquire.  This operation may fail spuriously
> >     * (typically, due to memory contention) even if the current value
> >     * does match the expected value.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return {@code true} if successful
> >     */
> >    boolean weakCompareAndSetAcquire(Object owner, T expected, T val);
> >
> >    /**
> >     * Possibly atomically sets the value to the given updated value
> >     * with the memory semantics of setRelease if the current value
> >     * {@code ==} the expected value, as as accessed with the memory
> >     * semantics of getRelaxed.  This operation may fail spuriously
> >     * (typically, due to memory contention) even if the current value
> >     * does match the expected value.
> >     *
> >     * @param expected the expected value
> >     * @param val the new value
> >     * @return {@code true} if successful
> >     */
> >    boolean weakCompareAndSetRelease(Object owner, T expected, T val);
> >
> >    // special RMW
> >
> >    /**
> >     * Atomically sets to the given value with the memory semantics of
> >     * setVolatile and returns the old value.
> >     *
> >     * @param newValue the new value
> >     * @return the previous value
> >     */
> >    T getAndSet(Object owner, T val);
> >
> >    /**
> >     * Atomically adds the given value to the current value with the
> >     * memory semantics of setVolatile.
> >     *
> >     * @param delta the value to add
> >     * @return the previous value
> >     */
> >    T getAndAdd(Object owner, T delta);
> >
> >    /**
> >     * Atomically adds the given value to the current value with the
> >     * memory semantics of setVolatile.
> >     *
> >     * @param delta the value to add
> >     * @return the current value
> >     */
> >    T addAndGet(Object owner, T delta);
> > }
> >
> > /**
> > * A set of methods providing fine-grained control of memory ordering.
> > *
> > * <p>The Java Language Specification permits operations to be
> > * executed in orders different than are apparent in program source
> > * code, subject to constraints mainly arising from the use of locks
> > * and volatile fields. The methods of this class can also be used to
> > * impose constraints. Their specifications are phrased in terms of
> > * the lack of "reorderings" -- observable ordering effects that might
> > * otherwise occur if the fence were not present.
> > *
> > * @apiNote More precise phrasing of these specifications may
> > * accompany future updates of the Java Language Specification.
> > */
> > public class Fences {
> >
> >    /**
> >     * Ensures that loads and stores before the fence will not be
> >     * reordered with loads and stores after the fence.
> >     *
> >     * @apiNote Ignoring the many semantic differences from C and
> >     * C++, this method has memory ordering effects compatible with
> >     * atomic_thread_fence(memory_order_seq_cst)
> >     */
> >    public static void fullFence() {}
> >
> >    /**
> >     * Ensures that loads before the fence will not be reordered with
> >     * loads and stores after the fence.
> >     *
> >     * @apiNote Ignoring the many semantic differences from C and
> >     * C++, this method has memory ordering effects compatible with
> >     * atomic_thread_fence(memory_order_acquire)
> >     */
> >    public static void acquireFence() {}
> >
> >    /**
> >     * Ensures that loads and stores before the fence will not be
> >     * reordered with stores after the fence.
> >     *
> >     * @apiNote Ignoring the many semantic differences from C and
> >     * C++, this method has memory ordering effects compatible with
> >     * atomic_thread_fence(memory_order_release)
> >     */
> >    public static void releaseFence() {}
> >
> >    /**
> >     * Ensures that loads before the fence will not be reordered with
> >     * loads after the fence.
> >     */
> >    public static void loadLoadFence() {}
> >
> >    /**
> >     * Ensures that stores before the fence will not be reordered with
> >     * stores after the fence.
> >     */
> >    public static void storeStoreFence() {}
> >
> > }
> >
> > class java.lang.ref.Reference {
> >    // add:
> >
> >    /**
> >     * Ensures that the object referenced by the given reference
> >     * remains <em>strongly reachable</em> (as defined in the {@link
> >     * java.lang.ref} package documentation), regardless of any prior
> >     * actions of the program that might otherwise cause the object to
> >     * become unreachable; thus, the referenced object is not
> >     * reclaimable by garbage collection at least until after the
> >     * invocation of this method. Invocation of this method does not
> >     * itself initiate garbage collection or finalization.
> >     *
> >     * @param ref the reference. If null, this method has no effect.
> >     */
> >    public static void reachabilityFence(Object ref) {}
> >
> > }
>
>

From peter.levart at gmail.com  Sun Aug 23 09:14:10 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 23 Aug 2015 11:14:10 +0200
Subject: hg: valhalla/valhalla/jdk: Initial implementation of metacircular
	interpreter
In-Reply-To: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
References: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
Message-ID: <55D98EE2.4010701@gmail.com>

Hi,

Very interesting. Are you prepared to give some hint as to what role the 
metacircular interpreter will play in the valhalla project or is it 
still a secret ?

Regards, Peter

On 08/21/2015 11:23 PM, brian.goetz at oracle.com wrote:
> Changeset: f0a19269be37
> Author:    briangoetz
> Date:      2015-08-21 17:23 -0400
> URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f0a19269be37
>
> Initial implementation of metacircular interpreter
>
> + interpreter/src/valhalla/interpreter/Frame.java
> + interpreter/src/valhalla/interpreter/Interpreter.java
> + interpreter/src/valhalla/interpreter/InterpreterError.java
> + interpreter/src/valhalla/interpreter/OpcodeHandler.java
> + interpreter/test/valhalla/interpreter/FrameTest.java
> + interpreter/test/valhalla/interpreter/InterpreterTest.java
> ! src/java.base/share/classes/java/anyutil/Spliterator.java
> ! src/java.base/share/classes/java/anyutil/stream/IntStream.java
> ! src/java.base/share/classes/java/anyutil/stream/Streams.java
>


From forax at univ-mlv.fr  Sun Aug 23 09:56:14 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 23 Aug 2015 09:56:14 +0000
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <55D73486.6050502@cs.oswego.edu>
References: <55D73486.6050502@cs.oswego.edu>
Message-ID: <606BB0D7-906D-4D00-9F71-FB0999ED5391@univ-mlv.fr>

Hi Doug,
is there a plan to update AtomicReferenceFieldUpdater (and variants) implementation too, by moving the implementation in java.lang.invoke and use the very same tricks that VarHandle implementations use ?

R?mi


Le 21 ao?t 2015 16:24:06 CEST, Doug Lea <dl at cs.oswego.edu> a ?crit :
>
>For those of you who haven't been following this on the jmm-dev list
>or follow-ups on concurrency-interest:
>
>We are NOT planning a full JMM memory model update for jdk9 -- there
>are still unresolved issues in revising the formal core model.
>However, jdk9 will include APIs for VarHandles (a scaled-down version
>of
>the "enhanced volatiles" JEP), that together with some other
>support replaces the need to use of Unsafe to obtain these
>effects and does so compatibly with C/C++11 atomics. To do this, we
>must, until the next full JMM update, provide specs that are
>clear to readers (at least those familiar with the underlying
>concepts) but not formally tied to a base model, (Which limits
>how much we can say in them.)
>
>The tentative methods are pasted below and also at
>   http://gee.cs.oswego.edu/dl/wwwtmp/Fodder.java
>The javadocs currently do not include any examples helping to
>explain why you would ever want to use any of these methods.
>
>The actual VarHandle class will look a bit different because
>it will rely on specializations of polymorphic signatures.
>(Current versions can be found in the openjdk mercurial
>"jdk9/sandbox" repo.) And the "Fences" method may end up
>in a different java.lang.* utility class. We'd also retrofit
>j.u.c.atomic.Atomic* classes to use compatible methods/names.
>
>Comments welcome.
>
>...
>
>/**
>  * Stand-in for spec purposes of jdk9 java.lang.invoke.VarHandle
>  */
>abstract class NotReallyVarHandle<T> {
>     // Load
>
>     /**
>      * Returns the value, with memory semantics of reading a
>      * non-volatile variable.
>      *
>      * @return the value
>      */
>     T getRelaxed(Object owner);
>
>     /**
>      * Returns the value, with memory semantics of reading a volatile
>      * variable.
>      *
>      * @return the value
>      */
>     T getVolatile(Object owner);
>
>     /**
>      * Returns the value, and ensures that subsequent loads and stores
>      * are not reordered before this access.
>      *
>      * @apiNote Ignoring the many semantic differences from C and
>      * C++, this method has memory ordering effects compatible with
>      * memory_order_acquire ordering.
>      *
>      * @return the value
>      */
>     T getAcquire(Object owner);
>
>     /**
>      * Returns the value, accessed in program order, but with no
>      * assurance of memory ordering effects with respect to other
>      * threads.
>      *
>      * @return the value
>      */
>     T getOpaque(Object owner);
>
>     // Store
>
>     /**
>      * Sets the value, with memory semantics of setting a non-volatile
>      * variable.
>      *
>      * @param val the new value
>      */
>     void setRelaxed(Object owner, T val);
>
>     /**
>      * Sets the value, with memory semantics of setting a volatile
>      * variable.
>      *
>      * @apiNote Ignoring the many semantic differences from C and
>      * C++, this method has memory ordering effects compatible with
>      * memory_order_seq_cst.
>      *
>      * @param val the new value
>      */
>     void setVolatile(Object owner, T val);
>
>     /**
>      * Sets the value, and ensures that prior loads and stores are not
>      * reordered after this access.
>      *
>      * @apiNote Ignoring the many semantic differences from C and
>      * C++, this method has memory ordering effects compatible with
>      * memory_order_release ordering.
>      *
>      * @param val the new value
>      */
>     void setRelease(Object owner, T val);
>
>     /**
>      * Sets the value, in program order, but with no assurance of
>      * memory ordering effects with respect to other threads.
>      *
>      * @param val the new value
>      */
>     void setOpaque(Object owner, T val);
>
>     // CAS
>
>     /**
>      * Atomically sets the value to the given updated value with the
>      * memory semantics of setVolatile if the current value {@code ==}
>      * the expected value, as accessed with the memory semantics of
>      * getVolatile.
>      *
>      * @param expected the expected value
>      * @param val the new value
>      * @return {@code true} if successful. False return indicates that
>      * the actual value was not equal to the expected value.
>      */
>     boolean compareAndSet(Object owner, T expected, T val);
>
>     // Value-returning compare and exchange
>
>     /**
>      * Atomically sets the value to the given updated value with the
>      * memory semantics of setVolatile if the current value {@code ==}
>      * the expected value, as accessed with the memory semantics of
>      * getVolatile.
>      *
>      * @param expected the expected value
>      * @param val the new value
>  * @return the current value, which will be the same as {@code val} if
>      * successful.
>      */
>     T compareAndExchangeVolatile(Object owner, T expected, T val);
>
>     /**
>      * Atomically sets the value to the given updated value with the
>      * memory semantics of setRelaxed if the current value {@code ==}
>      * the expected value, as accessed with the memory semantics of
>      * getAcquire.
>      *
>      * @param expected the expected value
>      * @param val the new value
>  * @return the current value, which will be the same as {@code val} if
>      * successful.
>      */
>     T compareAndExchangeAcquire(Object owner, T expected, T val);
>
>     /**
>      * Atomically sets the value to the given updated value with the
>      * memory semantics of setRelease if the current value {@code ==}
>      * the expected value, as accessed with the memory samantics of
>      * getRelease.
>      *
>      * @param expected the expected value
>      * @param val the new value
>  * @return the current value, which will be the same as {@code val} if
>      * successful.
>      */
>     T compareAndExchangeRelease(Object owner, T expected, T val);
>
>     // Weak (spurious failures allowed)
>
>     /**
>      * Possibly atomically sets the value to the given updated value
>      * with the semantics of setRelaxed if the current value {@code
>      * ==} the expected value, as as accessed with the memory
>      * semantics of getRelaxed.  This operation may fail spuriously
>      * (typically, due to memory contention) even if the current value
>      * does match the expected value.
>      *
>      * @param expected the expected value
>      * @param val the new value
>      * @return {@code true} if successful
>      */
>     boolean weakCompareAndSetRelaxed(Object owner, T expected, T val);
>
>     /**
>      * Possibly atomically sets the value to the given updated value
>      * with the memory semantics of setRelaxed if the current value
>      * {@code ==} the expected value, as as accessed with the memory
>      * semantics of getAcquire.  This operation may fail spuriously
>      * (typically, due to memory contention) even if the current value
>      * does match the expected value.
>      *
>      * @param expected the expected value
>      * @param val the new value
>      * @return {@code true} if successful
>      */
>     boolean weakCompareAndSetAcquire(Object owner, T expected, T val);
>
>     /**
>      * Possibly atomically sets the value to the given updated value
>      * with the memory semantics of setRelease if the current value
>      * {@code ==} the expected value, as as accessed with the memory
>      * semantics of getRelaxed.  This operation may fail spuriously
>      * (typically, due to memory contention) even if the current value
>      * does match the expected value.
>      *
>      * @param expected the expected value
>      * @param val the new value
>      * @return {@code true} if successful
>      */
>     boolean weakCompareAndSetRelease(Object owner, T expected, T val);
>
>     // special RMW
>
>     /**
>      * Atomically sets to the given value with the memory semantics of
>      * setVolatile and returns the old value.
>      *
>      * @param newValue the new value
>      * @return the previous value
>      */
>     T getAndSet(Object owner, T val);
>
>     /**
>      * Atomically adds the given value to the current value with the
>      * memory semantics of setVolatile.
>      *
>      * @param delta the value to add
>      * @return the previous value
>      */
>     T getAndAdd(Object owner, T delta);
>
>     /**
>      * Atomically adds the given value to the current value with the
>      * memory semantics of setVolatile.
>      *
>      * @param delta the value to add
>      * @return the current value
>      */
>     T addAndGet(Object owner, T delta);
>}
>
>/**
>  * A set of methods providing fine-grained control of memory ordering.
>  *
>  * <p>The Java Language Specification permits operations to be
>  * executed in orders different than are apparent in program source
>  * code, subject to constraints mainly arising from the use of locks
>  * and volatile fields. The methods of this class can also be used to
>  * impose constraints. Their specifications are phrased in terms of
>  * the lack of "reorderings" -- observable ordering effects that might
>  * otherwise occur if the fence were not present.
>  *
>  * @apiNote More precise phrasing of these specifications may
>  * accompany future updates of the Java Language Specification.
>  */
>public class Fences {
>
>     /**
>      * Ensures that loads and stores before the fence will not be
>      * reordered with loads and stores after the fence.
>      *
>      * @apiNote Ignoring the many semantic differences from C and
>      * C++, this method has memory ordering effects compatible with
>      * atomic_thread_fence(memory_order_seq_cst)
>      */
>     public static void fullFence() {}
>
>     /**
>      * Ensures that loads before the fence will not be reordered with
>      * loads and stores after the fence.
>      *
>      * @apiNote Ignoring the many semantic differences from C and
>      * C++, this method has memory ordering effects compatible with
>      * atomic_thread_fence(memory_order_acquire)
>      */
>     public static void acquireFence() {}
>
>     /**
>      * Ensures that loads and stores before the fence will not be
>      * reordered with stores after the fence.
>      *
>      * @apiNote Ignoring the many semantic differences from C and
>      * C++, this method has memory ordering effects compatible with
>      * atomic_thread_fence(memory_order_release)
>      */
>     public static void releaseFence() {}
>
>     /**
>      * Ensures that loads before the fence will not be reordered with
>      * loads after the fence.
>      */
>     public static void loadLoadFence() {}
>
>     /**
>      * Ensures that stores before the fence will not be reordered with
>      * stores after the fence.
>      */
>     public static void storeStoreFence() {}
>
>}
>
>class java.lang.ref.Reference {
>     // add:
>
>     /**
>      * Ensures that the object referenced by the given reference
>      * remains <em>strongly reachable</em> (as defined in the {@link
>      * java.lang.ref} package documentation), regardless of any prior
>      * actions of the program that might otherwise cause the object to
>      * become unreachable; thus, the referenced object is not
>      * reclaimable by garbage collection at least until after the
>      * invocation of this method. Invocation of this method does not
>      * itself initiate garbage collection or finalization.
>      *
>      * @param ref the reference. If null, this method has no effect.
>      */
>     public static void reachabilityFence(Object ref) {}
>
>}


From dl at cs.oswego.edu  Sun Aug 23 11:40:43 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 23 Aug 2015 07:40:43 -0400
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <2554DA3C-2F60-4B30-82CB-3BDDE4B3FA47@azulsystems.com>
References: <55D73486.6050502@cs.oswego.edu>
	<2554DA3C-2F60-4B30-82CB-3BDDE4B3FA47@azulsystems.com>
Message-ID: <55D9B13B.8050602@cs.oswego.edu>

On 08/22/2015 01:54 PM, Gil Tene wrote:
> Its' great to see storeStoreFence() and loadLoadFence() in the Fences class.
>
> For completeness, I would really like to see loadStoreFence() and
> storeLoadFence() there as well.

We're claiming that they are complete, as viewed as:

reads:  fullFence > acquireFence > loadLoadFence
writes: fullFence > releaseFence > storeStoreFence

We don't think that there are any defensible use cases that escape these,
and also no processor mappings that could exploit them.
In fact, even loadLoad seems to lack distinct mappings on processors
supported by hotspot, so will for now be internally equated to acquire.

-Doug


From dl at cs.oswego.edu  Sun Aug 23 11:46:47 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 23 Aug 2015 07:46:47 -0400
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <606BB0D7-906D-4D00-9F71-FB0999ED5391@univ-mlv.fr>
References: <55D73486.6050502@cs.oswego.edu>
	<606BB0D7-906D-4D00-9F71-FB0999ED5391@univ-mlv.fr>
Message-ID: <55D9B2A7.5050609@cs.oswego.edu>

On 08/23/2015 05:56 AM, R?mi Forax wrote:
> Hi Doug, is there a plan to update AtomicReferenceFieldUpdater (and variants)
> implementation too, by moving the implementation in java.lang.invoke and use
> the very same tricks that VarHandle implementations use ?

Only a vague plan to wait a bit to see how the VarHandle mechanics
play out and whether they apply in simple ways to FieldUpdaters,
and if so, contemplate doing this.

-Doug


From forax at univ-mlv.fr  Sun Aug 23 11:57:12 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 23 Aug 2015 11:57:12 +0000
Subject: hg: valhalla/valhalla/jdk: Initial implementation of
	metacircular	interpreter
In-Reply-To: <55D98EE2.4010701@gmail.com>
References: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
	<55D98EE2.4010701@gmail.com>
Message-ID: <851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>

Hi Peter,
my guess, let say you want to prototype the u-opcodes of John's talk at JVMLS.
What would you do ?

Btw, there is a complementary approach which is to use the existing bytecode interpreter and encode for every u-opcode a cascade of if/else on the type, the bytecode verifier will bark but you can deactivate it (the JIT may also crash if it is too curious a look the code of never executed branches).

R?mi 


Le 23 ao?t 2015 11:14:10 CEST, Peter Levart <peter.levart at gmail.com> a ?crit :
>Hi,
>
>Very interesting. Are you prepared to give some hint as to what role
>the 
>metacircular interpreter will play in the valhalla project or is it 
>still a secret ?
>
>Regards, Peter
>
>On 08/21/2015 11:23 PM, brian.goetz at oracle.com wrote:
>> Changeset: f0a19269be37
>> Author:    briangoetz
>> Date:      2015-08-21 17:23 -0400
>> URL:      
>http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f0a19269be37
>>
>> Initial implementation of metacircular interpreter
>>
>> + interpreter/src/valhalla/interpreter/Frame.java
>> + interpreter/src/valhalla/interpreter/Interpreter.java
>> + interpreter/src/valhalla/interpreter/InterpreterError.java
>> + interpreter/src/valhalla/interpreter/OpcodeHandler.java
>> + interpreter/test/valhalla/interpreter/FrameTest.java
>> + interpreter/test/valhalla/interpreter/InterpreterTest.java
>> ! src/java.base/share/classes/java/anyutil/Spliterator.java
>> ! src/java.base/share/classes/java/anyutil/stream/IntStream.java
>> ! src/java.base/share/classes/java/anyutil/stream/Streams.java
>>


From forax at univ-mlv.fr  Sun Aug 23 14:29:42 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 23 Aug 2015 14:29:42 +0000
Subject: hg: valhalla/valhalla/jdk: Initial implementation
	of	metacircular	interpreter
In-Reply-To: <851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>
References: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
	<55D98EE2.4010701@gmail.com>
	<851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>
Message-ID: <8CBDBAF7-B6B8-4BBD-8552-BD2F06FF1FD6@univ-mlv.fr>

Here is the prototypr i was talking about
https://github.com/forax/hello-specializ

seems to work well :)
R?mi 


Le 23 ao?t 2015 13:57:12 CEST, "R?mi Forax" <forax at univ-mlv.fr> a ?crit :
>Hi Peter,
>my guess, let say you want to prototype the u-opcodes of John's talk at
>JVMLS.
>What would you do ?
>
>Btw, there is a complementary approach which is to use the existing
>bytecode interpreter and encode for every u-opcode a cascade of if/else
>on the type, the bytecode verifier will bark but you can deactivate it
>(the JIT may also crash if it is too curious a look the code of never
>executed branches).
>
>R?mi 
>
>
>Le 23 ao?t 2015 11:14:10 CEST, Peter Levart <peter.levart at gmail.com> a
>?crit :
>>Hi,
>>
>>Very interesting. Are you prepared to give some hint as to what role
>>the 
>>metacircular interpreter will play in the valhalla project or is it 
>>still a secret ?
>>
>>Regards, Peter
>>
>>On 08/21/2015 11:23 PM, brian.goetz at oracle.com wrote:
>>> Changeset: f0a19269be37
>>> Author:    briangoetz
>>> Date:      2015-08-21 17:23 -0400
>>> URL:      
>>http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f0a19269be37
>>>
>>> Initial implementation of metacircular interpreter
>>>
>>> + interpreter/src/valhalla/interpreter/Frame.java
>>> + interpreter/src/valhalla/interpreter/Interpreter.java
>>> + interpreter/src/valhalla/interpreter/InterpreterError.java
>>> + interpreter/src/valhalla/interpreter/OpcodeHandler.java
>>> + interpreter/test/valhalla/interpreter/FrameTest.java
>>> + interpreter/test/valhalla/interpreter/InterpreterTest.java
>>> ! src/java.base/share/classes/java/anyutil/Spliterator.java
>>> ! src/java.base/share/classes/java/anyutil/stream/IntStream.java
>>> ! src/java.base/share/classes/java/anyutil/stream/Streams.java
>>>


From brian.goetz at oracle.com  Sun Aug 23 15:12:02 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 23 Aug 2015 11:12:02 -0400
Subject: hg: valhalla/valhalla/jdk: Initial implementation of metacircular
	interpreter
In-Reply-To: <851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>
References: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
	<55D98EE2.4010701@gmail.com>
	<851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>
Message-ID: <55D9E2C2.3090408@oracle.com>

> my guess, let say you want to prototype the u-opcodes of John's talk at JVMLS.

Yep, that's basically the motivation.  (Plus, it was fun.)  If we want 
to experiment with new bytecodes, its orders of magnitude cheaper to do 
the initial experiments in javac + metacircular interpreter than to do 
it in HotSpot.

> Btw, there is a complementary approach which is to use the existing bytecode interpreter and encode for every u-opcode a cascade of if/else on the type, the bytecode verifier will bark but you can deactivate it (the JIT may also crash if it is too curious a look the code of never executed branches).

Yes.  This might end up being a "Phase II" experimental strategy, after 
the MCE-based Phase I experiment runs its course.  But we don't want to 
start there, in part for the reasons you cite (must disable verifier, 
etc.)


From forax at univ-mlv.fr  Sun Aug 23 16:23:11 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 23 Aug 2015 16:23:11 +0000
Subject: hg: valhalla/valhalla/jdk: Initial implementation of metacircular
	interpreter
In-Reply-To: <55D9E2C2.3090408@oracle.com>
References: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
	<55D98EE2.4010701@gmail.com>
	<851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>
	<55D9E2C2.3090408@oracle.com>
Message-ID: <A9C7064A-FC6A-4D68-9971-B844D704B81E@univ-mlv.fr>



Le 23 ao?t 2015 17:12:02 CEST, Brian Goetz <brian.goetz at oracle.com> a ?crit :
>> my guess, let say you want to prototype the u-opcodes of John's talk
>at JVMLS.
>
>Yep, that's basically the motivation.  (Plus, it was fun.)  

very true, everyone should try to write such interpreter at least once, with lambdas and method handles it's exhilarating !

R?mi 

> If we want to experiment with new bytecodes, its orders of magnitude cheaper to do
>
>the initial experiments in javac + metacircular interpreter than to do 
>it in HotSpot.
>
>> Btw, there is a complementary approach which is to use the existing
>bytecode interpreter and encode for every u-opcode a cascade of if/else
>on the type, the bytecode verifier will bark but you can deactivate it
>(the JIT may also crash if it is too curious a look the code of never
>executed branches).
>
>Yes.  This might end up being a "Phase II" experimental strategy, after
>
>the MCE-based Phase I experiment runs its course.  But we don't want to
>
>start there, in part for the reasons you cite (must disable verifier, 
>etc.)


From brian.goetz at oracle.com  Sun Aug 23 16:53:19 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 23 Aug 2015 12:53:19 -0400
Subject: hg: valhalla/valhalla/jdk: Initial implementation of metacircular
	interpreter
In-Reply-To: <A9C7064A-FC6A-4D68-9971-B844D704B81E@univ-mlv.fr>
References: <201508212123.t7LLNnrj004857@aojmv0008.oracle.com>
	<55D98EE2.4010701@gmail.com>
	<851DD738-CFDE-45E5-AAB0-FBFDCBF23807@univ-mlv.fr>
	<55D9E2C2.3090408@oracle.com>
	<A9C7064A-FC6A-4D68-9971-B844D704B81E@univ-mlv.fr>
Message-ID: <55D9FA7F.3080201@oracle.com>

> very true, everyone should try to write such interpreter at least once, with lambdas and method handles it's exhilarating !

Yes.  The MH runtime probably replaced what would otherwise be 1000 
lines of code to handle all the peculiarities of method dispatch. 
Instead, we just ask resolveOrFail to resolve the dispatch for us, and 
then use revealDirect to determine if this is a call we can interpret 
(and if not, just invoke() the resulting MH, and push the result on the 
interpreter frame.)  Even supporting indy was only about 15 LoC.  The 
overall result was impressive; most bytecodes took 1 LoC and even the 
hardest ones took no more than 15.

It's not complete; we're missing a few opcodes (xxxSWITCH) and exception 
handling is a total mess (actually, a partial mess, since some of it is 
simply missing.)


From vitalyd at gmail.com  Sun Aug 23 17:37:35 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Sun, 23 Aug 2015 13:37:35 -0400
Subject: jdk9 VarHandle and Fence methods
In-Reply-To: <55D9B13B.8050602@cs.oswego.edu>
References: <55D73486.6050502@cs.oswego.edu>
	<2554DA3C-2F60-4B30-82CB-3BDDE4B3FA47@azulsystems.com>
	<55D9B13B.8050602@cs.oswego.edu>
Message-ID: <CAHjP37E8zVa7Y6Y0+vNbnt4+UT=1+Cy5U8sTcOmG0febQr10pQ@mail.gmail.com>

Doug,

There may not be a mapping to the cpu, but what about compiler barriers?
LoadLoad is cheaper than acquire since it would allow subsequent stores to
move before the load.

sent from my phone
On Aug 23, 2015 7:41 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

> On 08/22/2015 01:54 PM, Gil Tene wrote:
>
>> Its' great to see storeStoreFence() and loadLoadFence() in the Fences
>> class.
>>
>> For completeness, I would really like to see loadStoreFence() and
>> storeLoadFence() there as well.
>>
>
> We're claiming that they are complete, as viewed as:
>
> reads:  fullFence > acquireFence > loadLoadFence
> writes: fullFence > releaseFence > storeStoreFence
>
> We don't think that there are any defensible use cases that escape these,
> and also no processor mappings that could exploit them.
> In fact, even loadLoad seems to lack distinct mappings on processors
> supported by hotspot, so will for now be internally equated to acquire.
>
> -Doug
>
>

From john.r.rose at oracle.com  Wed Aug 26 23:45:32 2015
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Wed, 26 Aug 2015 23:45:32 +0000
Subject: hg: valhalla/valhalla/jdk: Implement switch bytecodes
Message-ID: <201508262345.t7QNjW7B018112@aojmv0008.oracle.com>

Changeset: d8c8d471f6c8
Author:    jrose
Date:      2015-08-26 16:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d8c8d471f6c8

Implement switch bytecodes

! interpreter/src/valhalla/interpreter/Interpreter.java
! interpreter/test/valhalla/interpreter/InterpreterTest.java


From brian.goetz at oracle.com  Fri Aug 28 00:34:28 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 28 Aug 2015 00:34:28 +0000
Subject: hg: valhalla/valhalla/jdk: Interpreter: initial steps towards value
	types. Frame now works only with signatures,
	not with live types.  Many gratuitous refactorings.
Message-ID: <201508280034.t7S0YSGq006144@aojmv0008.oracle.com>

Changeset: cb8e34020b71
Author:    briangoetz
Date:      2015-08-27 20:33 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/cb8e34020b71

Interpreter: initial steps towards value types.  Frame now works only with signatures, not with live types.  Many gratuitous refactorings.

! interpreter/src/valhalla/interpreter/Frame.java
! interpreter/src/valhalla/interpreter/Interpreter.java
! interpreter/test/valhalla/interpreter/FrameTest.java


From john.r.rose at oracle.com  Sat Aug 29 00:07:17 2015
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Sat, 29 Aug 2015 00:07:17 +0000
Subject: hg: valhalla/valhalla/jdk: Interpreter: Implement exception
	generation and handling. Improve linkage of names. Isolate
	"unsafe" parts.
Message-ID: <201508290007.t7T07HQV006813@aojmv0008.oracle.com>

Changeset: 6798bf09156a
Author:    jrose
Date:      2015-08-28 17:06 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6798bf09156a

Interpreter: Implement exception generation and handling.  Improve linkage of names.  Isolate "unsafe" parts.

! interpreter/src/valhalla/interpreter/Frame.java
! interpreter/src/valhalla/interpreter/Interpreter.java
! interpreter/src/valhalla/interpreter/InterpreterError.java
! interpreter/src/valhalla/interpreter/OpcodeHandler.java
! interpreter/test/valhalla/interpreter/InterpreterTest.java