From jgaltidor at gmail.com  Tue Sep  1 02:04:14 2015
From: jgaltidor at gmail.com (John Altidor)
Date: Mon, 31 Aug 2015 22:04:14 -0400
Subject: "Model 2" prototype status
Message-ID: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>

Hi Brian,

I am new to this mailing list.  My PhD dissertation covered subtyping with
variance and Java wildcards extensively, so the questions you raised in
this thread are very interesting to me.  I was wondering how you are
handling the translational aspects of wildcards and specialized generic
methods.

Your earlier post asked how to represent List<any> in bytecode.  Since
List<any> is a supertype of both List<int> and List<double>, for example,
type List<any> should only support operations that can be applied to both
List<int> and List<double>.  One such operation is counting the number of
elements using method List.size().  Which byte representation would support
being able to dispatch List.size() on both an instance of List<int> and an
instance of List<double>?

It seems such a byte representation would need to be independent of fields.
  The number of bytes needed to represent an instance differs among
primitive types (e.g. int and double).  As a result, it seems List<int> and
List< double> may differ in the number of bytes needed for their fields.
In that case, one could not know the number of bytes in the instance of
List<any> returned from the following method:

List<any> func(int input_num) {
  if(input_num is odd)
    return new List<int>();
  else
    return new List<double>();
}

In addition to type-independent methods such as List.size(), another
operation that is type safe to allow on an instance of List<any> is
wildcard capture.  Consider the generic method, swapFirstTwo, below that
just swaps the order of the first two elements in the input list.  It is
type safe to pass an instance of List<any> to this method (because no
runtime type error would occur).

<any T> void swapFirstTwo(List<T> list) {
  T first = list.getAndRemoveFirst();
  T second = list.getAndRemoveFirst();
  list.addToBeginning(first);
  list.addToBeginning(second);
}

Would two calls to method swapFirstTwo, one with a List<int> as input and
the other method call with a List<double> as input, result in two
specialized copies of method swapFirstTwo in byte code?  If that is the
case, what is the byte representation of method swapFirstTwo when the input
is an instance of List<any>?

Thank you,
John Altidor
http://jgaltidor.github.io/


From scolebourne at joda.org  Tue Sep  1 06:47:58 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 1 Sep 2015 07:47:58 +0100
Subject: "Model 2" prototype status
In-Reply-To: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
Message-ID: <CACzrW9Da38r5+zzj0PxUJsJoyyEZq0havhHyRdWrT-saRHcWZQ@mail.gmail.com>

Make sure you've watched the JVMLS videos which may answer some questions:
https://www.youtube.com/watch?v=uNgAFSUXuwc
https://www.youtube.com/watch?v=SPhJs4KpJBM

(they should be considered mandatory for participation in this list!)

Stephen


On 1 September 2015 at 03:04, John Altidor <jgaltidor at gmail.com> wrote:
> Hi Brian,
>
> I am new to this mailing list.  My PhD dissertation covered subtyping with
> variance and Java wildcards extensively, so the questions you raised in
> this thread are very interesting to me.  I was wondering how you are
> handling the translational aspects of wildcards and specialized generic
> methods.
>
> Your earlier post asked how to represent List<any> in bytecode.  Since
> List<any> is a supertype of both List<int> and List<double>, for example,
> type List<any> should only support operations that can be applied to both
> List<int> and List<double>.  One such operation is counting the number of
> elements using method List.size().  Which byte representation would support
> being able to dispatch List.size() on both an instance of List<int> and an
> instance of List<double>?
>
> It seems such a byte representation would need to be independent of fields.
>   The number of bytes needed to represent an instance differs among
> primitive types (e.g. int and double).  As a result, it seems List<int> and
> List< double> may differ in the number of bytes needed for their fields.
> In that case, one could not know the number of bytes in the instance of
> List<any> returned from the following method:
>
> List<any> func(int input_num) {
>   if(input_num is odd)
>     return new List<int>();
>   else
>     return new List<double>();
> }
>
> In addition to type-independent methods such as List.size(), another
> operation that is type safe to allow on an instance of List<any> is
> wildcard capture.  Consider the generic method, swapFirstTwo, below that
> just swaps the order of the first two elements in the input list.  It is
> type safe to pass an instance of List<any> to this method (because no
> runtime type error would occur).
>
> <any T> void swapFirstTwo(List<T> list) {
>   T first = list.getAndRemoveFirst();
>   T second = list.getAndRemoveFirst();
>   list.addToBeginning(first);
>   list.addToBeginning(second);
> }
>
> Would two calls to method swapFirstTwo, one with a List<int> as input and
> the other method call with a List<double> as input, result in two
> specialized copies of method swapFirstTwo in byte code?  If that is the
> case, what is the byte representation of method swapFirstTwo when the input
> is an instance of List<any>?
>
> Thank you,
> John Altidor
> http://jgaltidor.github.io/


From forax at univ-mlv.fr  Tue Sep  1 07:36:02 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 1 Sep 2015 09:36:02 +0200 (CEST)
Subject: "Model 2" prototype status
In-Reply-To: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
Message-ID: <1743476901.411680.1441092962204.JavaMail.zimbra@u-pem.fr>

Did a say that i really dislike the List<any> notation :)

answer (maybe) inlined

On 09/01/2015 04:04 AM, John Altidor wrote:
> Hi Brian,

i'm not Brian, but i will answer nevertheless.

>
>
> I am new to this mailing list. 

welcome :)

>  My PhD dissertation covered subtyping with
> variance and Java wildcards extensively, so the questions you raised in
> this thread are very interesting to me.  I was wondering how you are
> handling the translational aspects of wildcards and specialized generic
> methods.

is your dissertation available ?

>
>
> Your earlier post asked how to represent List<any> in bytecode.  Since
> List<any> is a supertype of both List<int> and List<double>, for example,
> type List<any> should only support operations that can be applied to both
> List<int> and List<double>.  One such operation is counting the number of
> elements using method List.size().  Which byte representation would support
> being able to dispatch List.size() on both an instance of List<int> and an
> instance of List<double> ?

Brian has suggested to create a fake interface containing the common operations with List<int> and List<double> implementing such interface. For me, List<any> should be erased to Object (oh no erasure) and invocation should be done using invokedynamic.

>
>
> It seems such a byte representation would need to be independent of fields.

fields access can be emulated using getters/setters as Brian said.

>
>   The number of bytes needed to represent an instance differs among
> primitive types (e.g. int and double).  As a result, it seems List<int> and
> List< double> may differ in the number of bytes needed for their fields.
> In that case, one could not know the number of bytes in the instance of
> List<any> returned from the following method:
>
> List<any> func(int input_num) {
>   if(input_num is odd)
>     return new List<int>();
>   else
>     return new List<double>();
> }

You use a getter which is implemented differently on each class.
In the case of invokedynamic, you don't even need to generate such getters
in the implementation of List<int> or List<double> because you can create
method handles that read/write fields at the expense of maybe having a
code less optimized if the number of implementations of List
(think List of different value typess) explode.

>
>
> In addition to type-independent methods such as List.size(), another
> operation that is type safe to allow on an instance of List<any> is
> wildcard capture. 

yes, very good comment !

>  Consider the generic method, swapFirstTwo, below that
> just swaps the order of the first two elements in the input list.  It is
> type safe to pass an instance of List<any> to this method (because no
> runtime type error would occur).
>
> <any T> void swapFirstTwo(List<T> list) {
>   T first = list.getAndRemoveFirst();
>   T second = list.getAndRemoveFirst();
>   list.addToBeginning(first);
>   list.addToBeginning(second);
> }
>
> Would two calls to method swapFirstTwo, one with a List<int> as input and
> the other method call with a List<double> as input, result in two
> specialized copies of method swapFirstTwo in byte code? 

yes, as far as i know there will be several specialization of swapFirstTo, but i don't think anybody as talked about wildcard capture on this list.

>  If that is the
> case, what is the byte representation of method swapFirstTwo when the input
> is an instance of List<any>?

I don't know how to implement the capture with the synthetic interface,
with invokedynamic, you first ask the class of the type parameter (the class of E for a List)
and then dispatch to the corresponding specialization.

>
>
> Thank you,
> John Altidor
> http://jgaltidor.github.io/

regards,
R?mi



From martijnverburg at gmail.com  Tue Sep  1 08:34:04 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 1 Sep 2015 09:34:04 +0100
Subject: "Model 2" prototype status
In-Reply-To: <CACzrW9Da38r5+zzj0PxUJsJoyyEZq0havhHyRdWrT-saRHcWZQ@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
	<CACzrW9Da38r5+zzj0PxUJsJoyyEZq0havhHyRdWrT-saRHcWZQ@mail.gmail.com>
Message-ID: <CAP7YuASkS3f88c7tnYd3pX6TPiLijFPrL_0J2x18OWr7gADVrA@mail.gmail.com>

Hi John/Stephen,

That's a good reminder!  For those new to this list, please see
http://openjdk.java.net/projects/valhalla/ as a starting point for your
explorations with Valhalls and what sort of feedback is most useful at this
stage.

I'll try to get the latest talks listed there shortly.

Cheers,
Martijn

On 1 September 2015 at 07:47, Stephen Colebourne <scolebourne at joda.org>
wrote:

> Make sure you've watched the JVMLS videos which may answer some questions:
> https://www.youtube.com/watch?v=uNgAFSUXuwc
> https://www.youtube.com/watch?v=SPhJs4KpJBM
>
> (they should be considered mandatory for participation in this list!)
>
> Stephen
>
>
> On 1 September 2015 at 03:04, John Altidor <jgaltidor at gmail.com> wrote:
> > Hi Brian,
> >
> > I am new to this mailing list.  My PhD dissertation covered subtyping
> with
> > variance and Java wildcards extensively, so the questions you raised in
> > this thread are very interesting to me.  I was wondering how you are
> > handling the translational aspects of wildcards and specialized generic
> > methods.
> >
> > Your earlier post asked how to represent List<any> in bytecode.  Since
> > List<any> is a supertype of both List<int> and List<double>, for example,
> > type List<any> should only support operations that can be applied to both
> > List<int> and List<double>.  One such operation is counting the number of
> > elements using method List.size().  Which byte representation would
> support
> > being able to dispatch List.size() on both an instance of List<int> and
> an
> > instance of List<double>?
> >
> > It seems such a byte representation would need to be independent of
> fields.
> >   The number of bytes needed to represent an instance differs among
> > primitive types (e.g. int and double).  As a result, it seems List<int>
> and
> > List< double> may differ in the number of bytes needed for their fields.
> > In that case, one could not know the number of bytes in the instance of
> > List<any> returned from the following method:
> >
> > List<any> func(int input_num) {
> >   if(input_num is odd)
> >     return new List<int>();
> >   else
> >     return new List<double>();
> > }
> >
> > In addition to type-independent methods such as List.size(), another
> > operation that is type safe to allow on an instance of List<any> is
> > wildcard capture.  Consider the generic method, swapFirstTwo, below that
> > just swaps the order of the first two elements in the input list.  It is
> > type safe to pass an instance of List<any> to this method (because no
> > runtime type error would occur).
> >
> > <any T> void swapFirstTwo(List<T> list) {
> >   T first = list.getAndRemoveFirst();
> >   T second = list.getAndRemoveFirst();
> >   list.addToBeginning(first);
> >   list.addToBeginning(second);
> > }
> >
> > Would two calls to method swapFirstTwo, one with a List<int> as input and
> > the other method call with a List<double> as input, result in two
> > specialized copies of method swapFirstTwo in byte code?  If that is the
> > case, what is the byte representation of method swapFirstTwo when the
> input
> > is an instance of List<any>?
> >
> > Thank you,
> > John Altidor
> > http://jgaltidor.github.io/
>


From jgaltidor at gmail.com  Tue Sep  1 12:27:22 2015
From: jgaltidor at gmail.com (John Altidor)
Date: Tue, 1 Sep 2015 08:27:22 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CAP7YuASkS3f88c7tnYd3pX6TPiLijFPrL_0J2x18OWr7gADVrA@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
	<CACzrW9Da38r5+zzj0PxUJsJoyyEZq0havhHyRdWrT-saRHcWZQ@mail.gmail.com>
	<CAP7YuASkS3f88c7tnYd3pX6TPiLijFPrL_0J2x18OWr7gADVrA@mail.gmail.com>
Message-ID: <CACqj5h7x2OULg-Xz7eQ+Fp41nqHO5n2sCGsJ-Xzq-cMCpGAABA@mail.gmail.com>

Hi Martin/Stephen,

Thanks for the links.  I haven't seen those videos before and are a great
starting point.

- John

On Tue, Sep 1, 2015 at 4:34 AM, Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi John/Stephen,
>
> That's a good reminder!  For those new to this list, please see
> http://openjdk.java.net/projects/valhalla/ as a starting point for your
> explorations with Valhalls and what sort of feedback is most useful at this
> stage.
>
> I'll try to get the latest talks listed there shortly.
>
> Cheers,
> Martijn
>
> On 1 September 2015 at 07:47, Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
> > Make sure you've watched the JVMLS videos which may answer some
> questions:
> > https://www.youtube.com/watch?v=uNgAFSUXuwc
> > https://www.youtube.com/watch?v=SPhJs4KpJBM
> >
> > (they should be considered mandatory for participation in this list!)
> >
> > Stephen
> >
> >
> > On 1 September 2015 at 03:04, John Altidor <jgaltidor at gmail.com> wrote:
> > > Hi Brian,
> > >
> > > I am new to this mailing list.  My PhD dissertation covered subtyping
> > with
> > > variance and Java wildcards extensively, so the questions you raised in
> > > this thread are very interesting to me.  I was wondering how you are
> > > handling the translational aspects of wildcards and specialized generic
> > > methods.
> > >
> > > Your earlier post asked how to represent List<any> in bytecode.  Since
> > > List<any> is a supertype of both List<int> and List<double>, for
> example,
> > > type List<any> should only support operations that can be applied to
> both
> > > List<int> and List<double>.  One such operation is counting the number
> of
> > > elements using method List.size().  Which byte representation would
> > support
> > > being able to dispatch List.size() on both an instance of List<int> and
> > an
> > > instance of List<double>?
> > >
> > > It seems such a byte representation would need to be independent of
> > fields.
> > >   The number of bytes needed to represent an instance differs among
> > > primitive types (e.g. int and double).  As a result, it seems List<int>
> > and
> > > List< double> may differ in the number of bytes needed for their
> fields.
> > > In that case, one could not know the number of bytes in the instance of
> > > List<any> returned from the following method:
> > >
> > > List<any> func(int input_num) {
> > >   if(input_num is odd)
> > >     return new List<int>();
> > >   else
> > >     return new List<double>();
> > > }
> > >
> > > In addition to type-independent methods such as List.size(), another
> > > operation that is type safe to allow on an instance of List<any> is
> > > wildcard capture.  Consider the generic method, swapFirstTwo, below
> that
> > > just swaps the order of the first two elements in the input list.  It
> is
> > > type safe to pass an instance of List<any> to this method (because no
> > > runtime type error would occur).
> > >
> > > <any T> void swapFirstTwo(List<T> list) {
> > >   T first = list.getAndRemoveFirst();
> > >   T second = list.getAndRemoveFirst();
> > >   list.addToBeginning(first);
> > >   list.addToBeginning(second);
> > > }
> > >
> > > Would two calls to method swapFirstTwo, one with a List<int> as input
> and
> > > the other method call with a List<double> as input, result in two
> > > specialized copies of method swapFirstTwo in byte code?  If that is the
> > > case, what is the byte representation of method swapFirstTwo when the
> > input
> > > is an instance of List<any>?
> > >
> > > Thank you,
> > > John Altidor
> > > http://jgaltidor.github.io/
> >
>


From jgaltidor at gmail.com  Tue Sep  1 12:37:39 2015
From: jgaltidor at gmail.com (John Altidor)
Date: Tue, 1 Sep 2015 08:37:39 -0400
Subject: "Model 2" prototype status
In-Reply-To: <1743476901.411680.1441092962204.JavaMail.zimbra@u-pem.fr>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
	<1743476901.411680.1441092962204.JavaMail.zimbra@u-pem.fr>
Message-ID: <CACqj5h76WYqux-eN=j_dQfwXsS7Lrp0=Y0vp7GEzPAs7BTfeUw@mail.gmail.com>

Thanks Remi for the direct responses.  Dynamically dispatching to
specialized versions of generic methods is an interesting idea for
supporting wildcard capture with any-instantiations.  Here is a link to my
dissertation:

http://jgaltidor.github.io/dissertation.pdf

Cheers,
- John


On Tue, Sep 1, 2015 at 3:36 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> Did a say that i really dislike the List<any> notation :)
>
> answer (maybe) inlined
>
> On 09/01/2015 04:04 AM, John Altidor wrote:
> > Hi Brian,
>
> i'm not Brian, but i will answer nevertheless.
>
> >
> >
> > I am new to this mailing list.
>
> welcome :)
>
> >  My PhD dissertation covered subtyping with
> > variance and Java wildcards extensively, so the questions you raised in
> > this thread are very interesting to me.  I was wondering how you are
> > handling the translational aspects of wildcards and specialized generic
> > methods.
>
> is your dissertation available ?
>
> >
> >
> > Your earlier post asked how to represent List<any> in bytecode.  Since
> > List<any> is a supertype of both List<int> and List<double>, for example,
> > type List<any> should only support operations that can be applied to both
> > List<int> and List<double>.  One such operation is counting the number of
> > elements using method List.size().  Which byte representation would
> support
> > being able to dispatch List.size() on both an instance of List<int> and
> an
> > instance of List<double> ?
>
> Brian has suggested to create a fake interface containing the common
> operations with List<int> and List<double> implementing such interface. For
> me, List<any> should be erased to Object (oh no erasure) and invocation
> should be done using invokedynamic.
>
> >
> >
> > It seems such a byte representation would need to be independent of
> fields.
>
> fields access can be emulated using getters/setters as Brian said.
>
> >
> >   The number of bytes needed to represent an instance differs among
> > primitive types (e.g. int and double).  As a result, it seems List<int>
> and
> > List< double> may differ in the number of bytes needed for their fields.
> > In that case, one could not know the number of bytes in the instance of
> > List<any> returned from the following method:
> >
> > List<any> func(int input_num) {
> >   if(input_num is odd)
> >     return new List<int>();
> >   else
> >     return new List<double>();
> > }
>
> You use a getter which is implemented differently on each class.
> In the case of invokedynamic, you don't even need to generate such getters
> in the implementation of List<int> or List<double> because you can create
> method handles that read/write fields at the expense of maybe having a
> code less optimized if the number of implementations of List
> (think List of different value typess) explode.
>
> >
> >
> > In addition to type-independent methods such as List.size(), another
> > operation that is type safe to allow on an instance of List<any> is
> > wildcard capture.
>
> yes, very good comment !
>
> >  Consider the generic method, swapFirstTwo, below that
> > just swaps the order of the first two elements in the input list.  It is
> > type safe to pass an instance of List<any> to this method (because no
> > runtime type error would occur).
> >
> > <any T> void swapFirstTwo(List<T> list) {
> >   T first = list.getAndRemoveFirst();
> >   T second = list.getAndRemoveFirst();
> >   list.addToBeginning(first);
> >   list.addToBeginning(second);
> > }
> >
> > Would two calls to method swapFirstTwo, one with a List<int> as input and
> > the other method call with a List<double> as input, result in two
> > specialized copies of method swapFirstTwo in byte code?
>
> yes, as far as i know there will be several specialization of swapFirstTo,
> but i don't think anybody as talked about wildcard capture on this list.
>
> >  If that is the
> > case, what is the byte representation of method swapFirstTwo when the
> input
> > is an instance of List<any>?
>
> I don't know how to implement the capture with the synthetic interface,
> with invokedynamic, you first ask the class of the type parameter (the
> class of E for a List)
> and then dispatch to the corresponding specialization.
>
> >
> >
> > Thank you,
> > John Altidor
> > http://jgaltidor.github.io/
>
> regards,
> R?mi
>
>


From kervin at sludev.com  Tue Sep  1 12:41:06 2015
From: kervin at sludev.com (Kervin Pierre)
Date: Tue, 1 Sep 2015 12:41:06 +0000
Subject: "Model 2" prototype status
In-Reply-To: <CACzrW9Da38r5+zzj0PxUJsJoyyEZq0havhHyRdWrT-saRHcWZQ@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
	<CACzrW9Da38r5+zzj0PxUJsJoyyEZq0havhHyRdWrT-saRHcWZQ@mail.gmail.com>
Message-ID: <1441111265.19531.11.camel@sludev.com>

Maybe there should be a "valhalla-discuss" which can be used for more
general discussion, leaving "-dev" list for feedback only?

Personally I see value in further discussion around the topics on this
list, but also understand the need to keep the list traffic to a
minimum.  

And "please discuss on the general list" a little more useful and
accommodating a response than "don't discuss here".

Best regards,
Kervin


On Tue, 2015-09-01 at 07:47 +0100, Stephen Colebourne wrote:
> Make sure you've watched the JVMLS videos which may answer some questions:
> https://www.youtube.com/watch?v=uNgAFSUXuwc
> https://www.youtube.com/watch?v=SPhJs4KpJBM
> 
> (they should be considered mandatory for participation in this list!)
> 
> Stephen
> 
> 
> On 1 September 2015 at 03:04, John Altidor <jgaltidor at gmail.com> wrote:
> > Hi Brian,
> >
> > I am new to this mailing list.  My PhD dissertation covered subtyping with
> > variance and Java wildcards extensively, so the questions you raised in
> > this thread are very interesting to me.  I was wondering how you are
> > handling the translational aspects of wildcards and specialized generic
> > methods.
> >
> > Your earlier post asked how to represent List<any> in bytecode.  Since
> > List<any> is a supertype of both List<int> and List<double>, for example,
> > type List<any> should only support operations that can be applied to both
> > List<int> and List<double>.  One such operation is counting the number of
> > elements using method List.size().  Which byte representation would support
> > being able to dispatch List.size() on both an instance of List<int> and an
> > instance of List<double>?
> >
> > It seems such a byte representation would need to be independent of fields.
> >   The number of bytes needed to represent an instance differs among
> > primitive types (e.g. int and double).  As a result, it seems List<int> and
> > List< double> may differ in the number of bytes needed for their fields.
> > In that case, one could not know the number of bytes in the instance of
> > List<any> returned from the following method:
> >
> > List<any> func(int input_num) {
> >   if(input_num is odd)
> >     return new List<int>();
> >   else
> >     return new List<double>();
> > }
> >
> > In addition to type-independent methods such as List.size(), another
> > operation that is type safe to allow on an instance of List<any> is
> > wildcard capture.  Consider the generic method, swapFirstTwo, below that
> > just swaps the order of the first two elements in the input list.  It is
> > type safe to pass an instance of List<any> to this method (because no
> > runtime type error would occur).
> >
> > <any T> void swapFirstTwo(List<T> list) {
> >   T first = list.getAndRemoveFirst();
> >   T second = list.getAndRemoveFirst();
> >   list.addToBeginning(first);
> >   list.addToBeginning(second);
> > }
> >
> > Would two calls to method swapFirstTwo, one with a List<int> as input and
> > the other method call with a List<double> as input, result in two
> > specialized copies of method swapFirstTwo in byte code?  If that is the
> > case, what is the byte representation of method swapFirstTwo when the input
> > is an instance of List<any>?
> >
> > Thank you,
> > John Altidor
> > http://jgaltidor.github.io/


From brian.goetz at oracle.com  Tue Sep  1 16:17:34 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 1 Sep 2015 12:17:34 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
Message-ID: <55E5CF9E.1090902@oracle.com>

Hi John;

The prototype in the valhalla repo is fairly functional (though by no 
means complete).  So I'll answer these with some code.  Of course, this 
is still a prototype, so everything will probably change.

If I have:

class Box<any T> {
     public T t;

     public T get() { return t; }
}

Compilation (currently) produces a combination erased class / template 
file (Box.java), and a wildcard interface (Box$$any):

brian:tmp$ javap -c Box\$\$any.class
Compiled from "Box.java"
interface Box$$any {
   public abstract java.lang.Object get();

   public abstract java.lang.Object t$get();

   public abstract java.lang.Object t$set(java.lang.Object);
}

We see that methods, and accessors for the getter and setter for the 
field 't', are lifted to the interface.  Box<any> (represented at 
runtime by Box$$any) becomes the common supertype between all 
instantiations of Box<T>.

Note that the signatures have some mangled types, which looks like 
erasure here (but is not exactly the same as erasure, and hence needs a 
new name -- call it "anyrasure".)  Ideally, the anyrasure of a type 
would be a common supertype of all possible instantiations of that type, 
but there's no common supertype between "Object" and "int", so we'll 
settle for a common conversion target.

The anyrasure of a bare type variable is its erasure; a reference 
instantiation need make no conversions, and a value instantiation needs 
to apply a boxing conversion to implement the methods of Box$$any. 
Clients accessing members through a concretely typed receiver bypass the 
boxing path since both client and implementation will already agree on 
member types.

What about when Foo<T> shows up in a signature?  Compiling this:

class Box<any T> {
     Box<T> me() { return this; }
}

yields

interface Box$$any {
   public abstract Box$$any me();
}

showing that the anyrasure of Box<any T> is the wildcard type Box<any> 
(which is a common supertype).  As I mentioned in my talk, we are 
working on a story for the anyrasure of T[] as well (but is not yet 
implemented.)

Mapping wildcards to interfaces is imperfect.  It works great for 
capturing subtyping using tools the VM already understands (which means 
lots of things Just Work).  It also leverages invokeinterface, which is 
good.  However, there are some obvious imperfections in the story, which 
we're currently working on:

  - What about protected and package members?  (In theory we could 
support these accessibilities on interfaces -- the "consistency brigade" 
would certainly applaud this -- but these have issues too (i.e., what 
does it mean for a public interface to have a 'package' member?  Only 
classes in that package can implement the interface?  That's kind of 
weird.))

  - Even if we did the above, what about private members?  Private 
members are not inherited, so dispatching through invokeinterface won't 
work, so that needs another story regardless.

  - What about reflection?  Currently, the way to reflect over "all 
instantiations of Foo" is to reflect over Foo.class.  But Foo.class is 
only the erased instantiation, so people will want the equivalent of 
reflecting over Foo<any>.  (This is one place where lifting the members 
to the interface really shines; an indy-centric approach would require 
getting there another way.)

  - How do we enforce finality?  There *are* multiple legitimate classes 
that implement Foo<any T> -- Foo<int> is a different class than 
Foo<erased>.  How do we enforce that only "legitimate" instantiations 
are allowed to implement Foo$$any?

  - Even ignoring finality, how do we prevent impersonation?  If we 
represent Foo<any> by Foo$$any at runtime, how do we keep someone from 
simply implementing Foo$$any but not respecting the invariants of Foo, 
and passing the fake to a method expecting a Foo<any>?

  - What about wildcard capture?  We need a story for this; we're not 
working on this quite yet.

  - Non-anyfied superclasses.  The case "class Foo<any T> extends Moo" 
is an annoying corner case, which messes up our story for subtyping 
checks (member access is easily dealt with in one of several ways.)

In the happy cases, many operations on anyfied types proceed quite 
nicely, leaning on existing VM mechanisms (subtyping, invokeinterface, 
reflection), so they "just work".  All the work is dealing with the 
unhappy cases.

With a big enough crowbar(s), each of these issues can be dealt with, 
but we're mindful of the risk of ending up with a pile of unrelated hacks.

OK, back to work!


On 8/31/2015 10:04 PM, John Altidor wrote:
> Hi Brian,
>
> I am new to this mailing list.  My PhD dissertation covered subtyping with
> variance and Java wildcards extensively, so the questions you raised in
> this thread are very interesting to me.  I was wondering how you are
> handling the translational aspects of wildcards and specialized generic
> methods.
>
> Your earlier post asked how to represent List<any> in bytecode.  Since
> List<any> is a supertype of both List<int> and List<double>, for example,
> type List<any> should only support operations that can be applied to both
> List<int> and List<double>.  One such operation is counting the number of
> elements using method List.size().  Which byte representation would support
> being able to dispatch List.size() on both an instance of List<int> and an
> instance of List<double>?
>
> It seems such a byte representation would need to be independent of fields.
>    The number of bytes needed to represent an instance differs among
> primitive types (e.g. int and double).  As a result, it seems List<int> and
> List< double> may differ in the number of bytes needed for their fields.
> In that case, one could not know the number of bytes in the instance of
> List<any> returned from the following method:
>
> List<any> func(int input_num) {
>    if(input_num is odd)
>      return new List<int>();
>    else
>      return new List<double>();
> }
>
> In addition to type-independent methods such as List.size(), another
> operation that is type safe to allow on an instance of List<any> is
> wildcard capture.  Consider the generic method, swapFirstTwo, below that
> just swaps the order of the first two elements in the input list.  It is
> type safe to pass an instance of List<any> to this method (because no
> runtime type error would occur).
>
> <any T> void swapFirstTwo(List<T> list) {
>    T first = list.getAndRemoveFirst();
>    T second = list.getAndRemoveFirst();
>    list.addToBeginning(first);
>    list.addToBeginning(second);
> }
>
> Would two calls to method swapFirstTwo, one with a List<int> as input and
> the other method call with a List<double> as input, result in two
> specialized copies of method swapFirstTwo in byte code?  If that is the
> case, what is the byte representation of method swapFirstTwo when the input
> is an instance of List<any>?
>
> Thank you,
> John Altidor
> http://jgaltidor.github.io/
>


From jgaltidor at gmail.com  Tue Sep  1 23:29:37 2015
From: jgaltidor at gmail.com (John Altidor)
Date: Tue, 1 Sep 2015 19:29:37 -0400
Subject: "Model 2" prototype status
In-Reply-To: <55E5CF9E.1090902@oracle.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
	<55E5CF9E.1090902@oracle.com>
Message-ID: <CACqj5h55ZQZvJQDh-imhpP3aTmoneF7wWSGaD8yPZWyOti-8dQ@mail.gmail.com>

Thanks for letting me know about the prototype and explaining many cases.
It will be interesting to see how interface Box$$any will be used with
wildcard capture or when an instance of Box<any> is passed to a generic
method that captures the actual type argument of Box.

- John

On Tue, Sep 1, 2015 at 12:17 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Hi John;
>
> The prototype in the valhalla repo is fairly functional (though by no
> means complete).  So I'll answer these with some code.  Of course, this is
> still a prototype, so everything will probably change.
>
> If I have:
>
> class Box<any T> {
>     public T t;
>
>     public T get() { return t; }
> }
>
> Compilation (currently) produces a combination erased class / template
> file (Box.java), and a wildcard interface (Box$$any):
>
> brian:tmp$ javap -c Box\$\$any.class
> Compiled from "Box.java"
> interface Box$$any {
>   public abstract java.lang.Object get();
>
>   public abstract java.lang.Object t$get();
>
>   public abstract java.lang.Object t$set(java.lang.Object);
> }
>
> We see that methods, and accessors for the getter and setter for the field
> 't', are lifted to the interface.  Box<any> (represented at runtime by
> Box$$any) becomes the common supertype between all instantiations of Box<T>.
>
> Note that the signatures have some mangled types, which looks like erasure
> here (but is not exactly the same as erasure, and hence needs a new name --
> call it "anyrasure".)  Ideally, the anyrasure of a type would be a common
> supertype of all possible instantiations of that type, but there's no
> common supertype between "Object" and "int", so we'll settle for a common
> conversion target.
>
> The anyrasure of a bare type variable is its erasure; a reference
> instantiation need make no conversions, and a value instantiation needs to
> apply a boxing conversion to implement the methods of Box$$any. Clients
> accessing members through a concretely typed receiver bypass the boxing
> path since both client and implementation will already agree on member
> types.
>
> What about when Foo<T> shows up in a signature?  Compiling this:
>
> class Box<any T> {
>     Box<T> me() { return this; }
> }
>
> yields
>
> interface Box$$any {
>   public abstract Box$$any me();
> }
>
> showing that the anyrasure of Box<any T> is the wildcard type Box<any>
> (which is a common supertype).  As I mentioned in my talk, we are working
> on a story for the anyrasure of T[] as well (but is not yet implemented.)
>
> Mapping wildcards to interfaces is imperfect.  It works great for
> capturing subtyping using tools the VM already understands (which means
> lots of things Just Work).  It also leverages invokeinterface, which is
> good.  However, there are some obvious imperfections in the story, which
> we're currently working on:
>
>  - What about protected and package members?  (In theory we could support
> these accessibilities on interfaces -- the "consistency brigade" would
> certainly applaud this -- but these have issues too (i.e., what does it
> mean for a public interface to have a 'package' member?  Only classes in
> that package can implement the interface?  That's kind of weird.))
>
>  - Even if we did the above, what about private members?  Private members
> are not inherited, so dispatching through invokeinterface won't work, so
> that needs another story regardless.
>
>  - What about reflection?  Currently, the way to reflect over "all
> instantiations of Foo" is to reflect over Foo.class.  But Foo.class is only
> the erased instantiation, so people will want the equivalent of reflecting
> over Foo<any>.  (This is one place where lifting the members to the
> interface really shines; an indy-centric approach would require getting
> there another way.)
>
>  - How do we enforce finality?  There *are* multiple legitimate classes
> that implement Foo<any T> -- Foo<int> is a different class than
> Foo<erased>.  How do we enforce that only "legitimate" instantiations are
> allowed to implement Foo$$any?
>
>  - Even ignoring finality, how do we prevent impersonation?  If we
> represent Foo<any> by Foo$$any at runtime, how do we keep someone from
> simply implementing Foo$$any but not respecting the invariants of Foo, and
> passing the fake to a method expecting a Foo<any>?
>
>  - What about wildcard capture?  We need a story for this; we're not
> working on this quite yet.
>
>  - Non-anyfied superclasses.  The case "class Foo<any T> extends Moo" is
> an annoying corner case, which messes up our story for subtyping checks
> (member access is easily dealt with in one of several ways.)
>
> In the happy cases, many operations on anyfied types proceed quite nicely,
> leaning on existing VM mechanisms (subtyping, invokeinterface, reflection),
> so they "just work".  All the work is dealing with the unhappy cases.
>
> With a big enough crowbar(s), each of these issues can be dealt with, but
> we're mindful of the risk of ending up with a pile of unrelated hacks.
>
> OK, back to work!
>
>
>
> On 8/31/2015 10:04 PM, John Altidor wrote:
>
>> Hi Brian,
>>
>> I am new to this mailing list.  My PhD dissertation covered subtyping with
>> variance and Java wildcards extensively, so the questions you raised in
>> this thread are very interesting to me.  I was wondering how you are
>> handling the translational aspects of wildcards and specialized generic
>> methods.
>>
>> Your earlier post asked how to represent List<any> in bytecode.  Since
>> List<any> is a supertype of both List<int> and List<double>, for example,
>> type List<any> should only support operations that can be applied to both
>> List<int> and List<double>.  One such operation is counting the number of
>> elements using method List.size().  Which byte representation would
>> support
>> being able to dispatch List.size() on both an instance of List<int> and an
>> instance of List<double>?
>>
>> It seems such a byte representation would need to be independent of
>> fields.
>>    The number of bytes needed to represent an instance differs among
>> primitive types (e.g. int and double).  As a result, it seems List<int>
>> and
>> List< double> may differ in the number of bytes needed for their fields.
>> In that case, one could not know the number of bytes in the instance of
>> List<any> returned from the following method:
>>
>> List<any> func(int input_num) {
>>    if(input_num is odd)
>>      return new List<int>();
>>    else
>>      return new List<double>();
>> }
>>
>> In addition to type-independent methods such as List.size(), another
>> operation that is type safe to allow on an instance of List<any> is
>> wildcard capture.  Consider the generic method, swapFirstTwo, below that
>> just swaps the order of the first two elements in the input list.  It is
>> type safe to pass an instance of List<any> to this method (because no
>> runtime type error would occur).
>>
>> <any T> void swapFirstTwo(List<T> list) {
>>    T first = list.getAndRemoveFirst();
>>    T second = list.getAndRemoveFirst();
>>    list.addToBeginning(first);
>>    list.addToBeginning(second);
>> }
>>
>> Would two calls to method swapFirstTwo, one with a List<int> as input and
>> the other method call with a List<double> as input, result in two
>> specialized copies of method swapFirstTwo in byte code?  If that is the
>> case, what is the byte representation of method swapFirstTwo when the
>> input
>> is an instance of List<any>?
>>
>> Thank you,
>> John Altidor
>> http://jgaltidor.github.io/
>>
>>


From brian.goetz at oracle.com  Tue Sep  1 23:51:17 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 1 Sep 2015 19:51:17 -0400
Subject: "Model 2" prototype status
In-Reply-To: <CACqj5h55ZQZvJQDh-imhpP3aTmoneF7wWSGaD8yPZWyOti-8dQ@mail.gmail.com>
References: <CACqj5h7ninE31s7wLA3CoZ4AQaBhJC=EGNey7b58q-qhRc+mgw@mail.gmail.com>
	<55E5CF9E.1090902@oracle.com>
	<CACqj5h55ZQZvJQDh-imhpP3aTmoneF7wWSGaD8yPZWyOti-8dQ@mail.gmail.com>
Message-ID: <55E639F5.7@oracle.com>

> Thanks for letting me know about the prototype and explaining many
> cases.  It will be interesting to see how interface Box$$any will be
> used with wildcard capture or when an instance of Box<any> is passed to
> a generic method that captures the actual type argument of Box.

Yes, it will :)  We'll let you know when we figure that out...


From peter.levart at gmail.com  Sun Sep  6 09:10:16 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 6 Sep 2015 11:10:16 +0200
Subject: new jimage layout and IDEA 15 EAP
Message-ID: <55EC02F8.9090203@gmail.com>

Hi,

It is a pleasure to play with valhalla while the EAP release of IDEA 15 
already supports some of it's experimental features. But EAP IDEA 
releases expire quickly and get replaced with newer releases. Latest EAP 
release of IDEA already changed the support for new jdk9 jimage 
filesystem layout (8080511) so it now fails to detect the JDK classes of 
a valhalla build which hasn't updated to this new layout yet.

Are there any plans to sync valhalla with jdk9 soon?

Regards, Peter



From maurizio.cimadamore at oracle.com  Mon Sep  7 10:57:06 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 7 Sep 2015 11:57:06 +0100
Subject: new jimage layout and IDEA 15 EAP
In-Reply-To: <55EC02F8.9090203@gmail.com>
References: <55EC02F8.9090203@gmail.com>
Message-ID: <55ED6D82.7030106@oracle.com>

It's on my radar

Maurizio

On 06/09/15 10:10, Peter Levart wrote:
> Hi,
>
> It is a pleasure to play with valhalla while the EAP release of IDEA 
> 15 already supports some of it's experimental features. But EAP IDEA 
> releases expire quickly and get replaced with newer releases. Latest 
> EAP release of IDEA already changed the support for new jdk9 jimage 
> filesystem layout (8080511) so it now fails to detect the JDK classes 
> of a valhalla build which hasn't updated to this new layout yet.
>
> Are there any plans to sync valhalla with jdk9 soon?
>
> Regards, Peter
>



From peter.levart at gmail.com  Mon Sep  7 11:25:51 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 7 Sep 2015 13:25:51 +0200
Subject: new jimage layout and IDEA 15 EAP
In-Reply-To: <55ED6D82.7030106@oracle.com>
References: <55EC02F8.9090203@gmail.com> <55ED6D82.7030106@oracle.com>
Message-ID: <55ED743F.3040809@gmail.com>

There's no rush. I managed to locally apply just the changesets for 
"8080511: Refresh of jimage support" and IDEA works happily with such 
build...

Regards, Peter

On 09/07/2015 12:57 PM, Maurizio Cimadamore wrote:
> It's on my radar
>
> Maurizio
>
> On 06/09/15 10:10, Peter Levart wrote:
>> Hi,
>>
>> It is a pleasure to play with valhalla while the EAP release of IDEA 
>> 15 already supports some of it's experimental features. But EAP IDEA 
>> releases expire quickly and get replaced with newer releases. Latest 
>> EAP release of IDEA already changed the support for new jdk9 jimage 
>> filesystem layout (8080511) so it now fails to detect the JDK classes 
>> of a valhalla build which hasn't updated to this new layout yet.
>>
>> Are there any plans to sync valhalla with jdk9 soon?
>>
>> Regards, Peter
>>
>



From roman.shevchenko at jetbrains.com  Mon Sep  7 12:40:51 2015
From: roman.shevchenko at jetbrains.com (Roman Shevchenko)
Date: Mon, 7 Sep 2015 15:40:51 +0300
Subject: new jimage layout and IDEA 15 EAP
In-Reply-To: <55EC02F8.9090203@gmail.com>
References: <55EC02F8.9090203@gmail.com>
Message-ID: <55ED85D3.8020100@jetbrains.com>

Next IDEA EAP (expected tomorrow) will support both old and new layouts.

On 06/09/15 12:10, Peter Levart wrote:
> Hi,
>
> It is a pleasure to play with valhalla while the EAP release of IDEA 
> 15 already supports some of it's experimental features. But EAP IDEA 
> releases expire quickly and get replaced with newer releases. Latest 
> EAP release of IDEA already changed the support for new jdk9 jimage 
> filesystem layout (8080511) so it now fails to detect the JDK classes 
> of a valhalla build which hasn't updated to this new layout yet.
>
> Are there any plans to sync valhalla with jdk9 soon?
>
> Regards, Peter


From maurizio.cimadamore at oracle.com  Tue Sep 15 13:43:17 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 15 Sep 2015 13:43:17 +0000
Subject: hg: valhalla/valhalla/langtools: Javac should emit vgetfield for
	value members
Message-ID: <201509151343.t8FDhHjL009339@aojmv0008.oracle.com>

Changeset: a69a4ad71607
Author:    mcimadamore
Date:      2015-09-15 14:42 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a69a4ad71607

Javac should emit vgetfield for value members
Contributed-by: michael.haupt at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/classfile/Opcode.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ByteCodes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java



From maurizio.cimadamore at oracle.com  Wed Sep 16 13:56:50 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 16 Sep 2015 13:56:50 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: specialization doesn't handle
	method references that are not desugared into lambdas.
Message-ID: <201509161356.t8GDuoLu001703@aojmv0008.oracle.com>

Changeset: e3ad728a2007
Author:    mcimadamore
Date:      2015-09-16 14:56 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e3ad728a2007

Fix: specialization doesn't handle method references that are not desugared into lambdas.

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
+ test/tools/javac/valhalla/typespec/Lambda03.java



From maurizio.cimadamore at oracle.com  Tue Sep 22 11:55:22 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 22 Sep 2015 11:55:22 +0000
Subject: hg: valhalla/valhalla/langtools: Add support for new constant pool
	forms for generic type entries
Message-ID: <201509221155.t8MBtM9F007576@aojmv0008.oracle.com>

Changeset: dcdfe0afc39c
Author:    mcimadamore
Date:      2015-09-22 12:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/dcdfe0afc39c

Add support for new constant pool forms for generic type entries
* Add javac and javap support for generic type entries in constant pool
* Add new 'typed' opcode to handle type 1 opcodes
* Add support for type 2 and type 3 bytecodes through pointers to generic constant pool type entries
* Add flag to optionally turn on the new CP forms: -XDpoolModes=<MODE> where mode can be one of {all, type1, type2, type3}; modes can be negated with a '-' prefix - i.e. -XDpoolModes=all,-type2
* Bump minor classfile version if classfile contains new CP forms

Todo:
* ClassReader doesn not understand new forms
* type 4 opcodes not supported
* new CP forms in descriptors not supported
* new CP forms should be used instead of name mangling

! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassTranslator.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/Dependencies.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/Opcode.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/ReferenceFinder.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ByteCodes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
! src/jdk.compiler/share/classes/com/sun/tools/javap/ConstantWriter.java
! test/tools/javac/lambda/ByteCodeTest.java



From maurizio.cimadamore at oracle.com  Tue Sep 22 11:57:10 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 22 Sep 2015 11:57:10 +0000
Subject: hg: valhalla/valhalla/hotspot: Make ClassFileParser reobust to minor
	classfile version bump
Message-ID: <201509221157.t8MBvAeK007959@aojmv0008.oracle.com>

Changeset: bb2da3edfff1
Author:    mcimadamore
Date:      2015-09-22 12:56 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bb2da3edfff1

Make ClassFileParser reobust to minor classfile version bump

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



From maurizio.cimadamore at oracle.com  Tue Sep 22 15:27:39 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 22 Sep 2015 15:27:39 +0000
Subject: hg: valhalla/valhalla/langtools: New constant pool forms enhancements:
Message-ID: <201509221527.t8MFRdke012508@aojmv0008.oracle.com>

Changeset: 0bbfc370f185
Author:    mcimadamore
Date:      2015-09-22 16:27 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0bbfc370f185

New constant pool forms enhancements:
* new CP forms in descriptors (poolModes=signatures)
* new CP forms should be used instead of name mangling (poolModes=specialized)
* fix bug where logic for emitting invokespecial doesn't expect SignatureMember

! src/jdk.compiler/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/Descriptor.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java



From maurizio.cimadamore at oracle.com  Tue Sep 22 16:59:22 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 22 Sep 2015 16:59:22 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: CompoundType entries have wrong
	descriptor for arrays
Message-ID: <201509221659.t8MGxMWw007672@aojmv0008.oracle.com>

Changeset: 5ab7aaaf31e2
Author:    mcimadamore
Date:      2015-09-22 17:53 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/5ab7aaaf31e2

Fix: CompoundType entries have wrong descriptor for arrays

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java



From maurizio.cimadamore at oracle.com  Tue Sep 22 17:19:56 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 22 Sep 2015 17:19:56 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: better rendering of
	ParameterizedType entries in javap
Message-ID: <201509221719.t8MHJuxu013098@aojmv0008.oracle.com>

Changeset: 237c948465b8
Author:    mcimadamore
Date:      2015-09-22 18:19 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/237c948465b8

Enhancement: better rendering of ParameterizedType entries in javap

! src/jdk.compiler/share/classes/com/sun/tools/classfile/ConstantPool.java



From maurizio.cimadamore at oracle.com  Mon Sep 28 10:45:51 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 28 Sep 2015 10:45:51 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: when running in -XDpoolModes,
	javac emit generic class entries for non-generic types
Message-ID: <201509281045.t8SAjquO012369@aojmv0008.oracle.com>

Changeset: 64cc5da0193d
Author:    mcimadamore
Date:      2015-09-28 11:45 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/64cc5da0193d

Fix: when running in -XDpoolModes, javac emit generic class entries for non-generic types

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java



From maurizio.cimadamore at oracle.com  Tue Sep 29 09:26:22 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 29 Sep 2015 09:26:22 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: CompoundType entries for method
	signatures erroneously contains commas
Message-ID: <201509290926.t8T9QMhP020915@aojmv0008.oracle.com>

Changeset: dce04deaafe4
Author:    mcimadamore
Date:      2015-09-29 10:25 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/dce04deaafe4

Fix: CompoundType entries for method signatures erroneously contains commas
Enhancement: augment javap -s mode to show descriptors constant pool indices

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/jdk.compiler/share/classes/com/sun/tools/javap/ClassWriter.java



From maurizio.cimadamore at oracle.com  Tue Sep 29 10:07:40 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 29 Sep 2015 10:07:40 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: augment javap -s mode
	to show 'this',
	'superclass' and 'interfaces' indices (while also in -v mode)
Message-ID: <201509291007.t8TA7eh8002481@aojmv0008.oracle.com>

Changeset: c679e5428d92
Author:    mcimadamore
Date:      2015-09-29 11:07 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c679e5428d92

Enhancement: augment javap -s mode to show 'this', 'superclass' and 'interfaces' indices (while also in -v mode)

! src/jdk.compiler/share/classes/com/sun/tools/javap/ClassWriter.java



From timo.kinnunen at gmail.com  Tue Sep 29 12:58:56 2015
From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com)
Date: Tue, 29 Sep 2015 14:58:56 +0200
Subject: Time to rebase on top of JDK 9 repository?
Message-ID: <560a8b13.2975c20a.8918b.5f57@mx.google.com>

Hi, 

I?ve been looking into compiling Valhalla with Visual Studio 2015 to try it out but I have hit a snag. See, I have made the needed changes and have a working build but I made the changes on top of the jdk9/jdk9 repository. I tried bringing the changes over to the valhalla/valhalla repository but the valhalla repository seems to be several months behind the JDK 9 repositories. There?s quite a lot of changes missing. Is it time to merge in the latest JDK 9 changes?

I?m not an expert on mercurial nor familiar with the valhalla implementation details so I?m otherwise pretty much stuck.




Sent from Mail for Windows 10


From maurizio.cimadamore at oracle.com  Tue Sep 29 13:10:14 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 29 Sep 2015 14:10:14 +0100
Subject: Time to rebase on top of JDK 9 repository?
In-Reply-To: <560a8b13.2975c20a.8918b.5f57@mx.google.com>
References: <560a8b13.2975c20a.8918b.5f57@mx.google.com>
Message-ID: <560A8DB6.5060006@oracle.com>



On 29/09/15 13:58, timo.kinnunen at gmail.com wrote:
> Hi,
>
> I?ve been looking into compiling Valhalla with Visual Studio 2015 to try it out but I have hit a snag. See, I have made the needed changes and have a working build but I made the changes on top of the jdk9/jdk9 repository. I tried bringing the changes over to the valhalla/valhalla repository but the valhalla repository seems to be several months behind the JDK 9 repositories. There?s quite a lot of changes missing. Is it time to merge in the latest JDK 9 changes?
>
> I?m not an expert on mercurial nor familiar with the valhalla implementation details so I?m otherwise pretty much stuck.
Yep - I agree it's time to merge - it's on my radar; as a short-term 
measure, is there any specific changeset you need pushed in order to get 
up and running with VS2015?

Maurizio
>
>
>
> Sent from Mail for Windows 10



From timo.kinnunen at gmail.com  Tue Sep 29 13:35:33 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Tue, 29 Sep 2015 15:35:33 +0200
Subject: Time to rebase on top of JDK 9 repository?
In-Reply-To: <560A8DB6.5060006@oracle.com>
References: <560a8b13.2975c20a.8918b.5f57@mx.google.com>
	<560A8DB6.5060006@oracle.com>
Message-ID: <560a93a7.a267b40a.295f0.61b5@mx.google.com>

I?m not sure what exactly would be sufficient, but biggest problems are with reorganized C/C++ files in jdk9/hotspot and jdk9/jdk repositories. I also have small changes to autoconf templates in the root jdk9 repository. They are easy enough to add if the build is otherwise functional.

I could try with only the build changes included to see how far it goes.




Sent from Mail for Windows 10



From: Maurizio Cimadamore
Sent: Tuesday, September 29, 2015 15:10
To: timo.kinnunen at gmail.com;valhalla-dev at openjdk.java.net
Subject: Re: Time to rebase on top of JDK 9 repository?




On 29/09/15 13:58, timo.kinnunen at gmail.com wrote:
> Hi,
>
> I?ve been looking into compiling Valhalla with Visual Studio 2015 to try it out but I have hit a snag. See, I have made the needed changes and have a working build but I made the changes on top of the jdk9/jdk9 repository. I tried bringing the changes over to the valhalla/valhalla repository but the valhalla repository seems to be several months behind the JDK 9 repositories. There?s quite a lot of changes missing. Is it time to merge in the latest JDK 9 changes?
>
> I?m not an expert on mercurial nor familiar with the valhalla implementation details so I?m otherwise pretty much stuck.
Yep - I agree it's time to merge - it's on my radar; as a short-term 
measure, is there any specific changeset you need pushed in order to get 
up and running with VS2015?

Maurizio
>
>
>
> Sent from Mail for Windows 10





From brian.goetz at oracle.com  Tue Sep 29 18:42:35 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 29 Sep 2015 18:42:35 +0000
Subject: hg: valhalla/valhalla/jdk: First cut at model 3 converter;
	if we detect classfile 52.1 when loading, divert to model 3 rewriter
Message-ID: <201509291842.t8TIgZI7008391@aojmv0008.oracle.com>

Changeset: bf66aeeef857
Author:    briangoetz
Date:      2015-09-29 14:34 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bf66aeeef857

First cut at model 3 converter; if we detect classfile 52.1 when loading, divert to model 3 rewriter

! src/java.base/share/classes/java/net/URLClassLoader.java
+ src/java.base/share/classes/valhalla/model3/Model3Converter.java
+ src/java.base/share/classes/valhalla/model3/SpeciesKey.java



From brian.goetz at oracle.com  Tue Sep 29 18:51:50 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 29 Sep 2015 18:51:50 +0000
Subject: hg: valhalla/valhalla/langtools: Hacks to classfile reader/writer
	library to support easier class rewriting
Message-ID: <201509291851.t8TIpokG010499@aojmv0008.oracle.com>

Changeset: 95acce55a36d
Author:    briangoetz
Date:      2015-09-29 13:38 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/95acce55a36d

Hacks to classfile reader/writer library to support easier class rewriting

! src/jdk.compiler/share/classes/com/sun/tools/classfile/Code_attribute.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/ConstantPool.java



From timo.kinnunen at gmail.com  Wed Sep 30 12:56:13 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 30 Sep 2015 12:56:13 +0000 (UTC)
Subject: Time to rebase on top of JDK 9 repository?
In-Reply-To: <560a93a7.a267b40a.295f0.61b5@mx.google.com>
References: <560a8b13.2975c20a.8918b.5f57@mx.google.com>
	<560A8DB6.5060006@oracle.com>
	<560a93a7.a267b40a.295f0.61b5@mx.google.com>
Message-ID: <81B4C4AAF750542E.0AA09FB2-C7F4-4B50-B136-9CBD95A2FB65@mail.outlook.com>

I tried this but there's quite a lot of compile errors from constructs that were legal in C++11 but are not in C++14 that have been cleaned in the jdk9 already. For example many macros get interpreted as user-defined literals.
So the merge to get these is needed.


Sent from Outlook

    _____________________________
From: Timo Kinnunen <timo.kinnunen at gmail.com>
Sent: Tuesday, September 29, 2015 3:35 pm
Subject: RE: Time to rebase on top of JDK 9 repository?
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>,  <valhalla-dev at openjdk.java.net>


              

I?m not sure what exactly would be sufficient, but biggest problems are with reorganized C/C++ files in jdk9/hotspot and jdk9/jdk repositories. I also have small changes to autoconf templates in the root jdk9 repository. They are easy enough to add if the build is otherwise functional.   

?   

I could try with only the build changes included to see how far it goes.   

?   

?   

?   

?   

Sent from Mail for Windows 10   

?   

?       


From: Maurizio Cimadamore
Sent: Tuesday, September 29, 2015 15:10
To: timo.kinnunen at gmail.com;valhalla-dev at openjdk.java.net
Subject: Re: Time to rebase on top of JDK 9 repository?      

?   

?   

?   

?   

On 29/09/15 13:58, timo.kinnunen at gmail.com wrote:   

> Hi,   

>?   

> I?ve been looking into compiling Valhalla with Visual Studio 2015 to try it out but I have hit a snag. See, I have made the needed changes and have a working build but I made the changes on top of the jdk9/jdk9 repository. I tried bringing the changes over to the valhalla/valhalla repository but the valhalla repository seems to be several months behind the JDK 9 repositories. There?s quite a lot of changes missing. Is it time to merge in the latest JDK 9 changes?   

>?   

> I?m not an expert on mercurial nor familiar with the valhalla implementation details so I?m otherwise pretty much stuck.   

Yep - I agree it's time to merge - it's on my radar; as a short-term    

measure, is there any specific changeset you need pushed in order to get    

up and running with VS2015?   

?   

Maurizio   

>?   

>?   

>?   

> Sent from Mail for Windows 10   

?   

?   

?

From maurizio.cimadamore at oracle.com  Wed Sep 30 13:42:24 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 30 Sep 2015 14:42:24 +0100
Subject: Time to rebase on top of JDK 9 repository?
In-Reply-To: <81B4C4AAF750542E.0AA09FB2-C7F4-4B50-B136-9CBD95A2FB65@mail.outlook.com>
References: <560a8b13.2975c20a.8918b.5f57@mx.google.com>
	<560A8DB6.5060006@oracle.com>
	<560a93a7.a267b40a.295f0.61b5@mx.google.com>
	<81B4C4AAF750542E.0AA09FB2-C7F4-4B50-B136-9CBD95A2FB65@mail.outlook.com>
Message-ID: <560BE6C0.6090408@oracle.com>



On 30/09/15 13:56, Timo Kinnunen wrote:
> I tried this but there's quite a lot of compile errors from constructs 
> that were legal in C++11 but are not in C++14 that have been cleaned 
> in the jdk9 already. For example many macros get interpreted as 
> user-defined literals.
>
> So the merge to get these is needed.
ok - thx for trying.

Maurizio
>
>
>
> Sent from Outlook <http://aka.ms/Ox5hz3>
>
> _____________________________
> From: Timo Kinnunen <timo.kinnunen at gmail.com 
> <mailto:timo.kinnunen at gmail.com>>
> Sent: Tuesday, September 29, 2015 3:35 pm
> Subject: RE: Time to rebase on top of JDK 9 repository?
> To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>>, 
> <valhalla-dev at openjdk.java.net <mailto:valhalla-dev at openjdk.java.net>>
>
>
> I?m not sure what exactly would be sufficient, but biggest problems 
> are with reorganized C/C++ files in jdk9/hotspot and jdk9/jdk 
> repositories. I also have small changes to autoconf templates in the 
> root jdk9 repository. They are easy enough to add if the build is 
> otherwise functional.
>
> I could try with only the build changes included to see how far it goes.
>
> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
>
> *From: *Maurizio Cimadamore
> *Sent: *Tuesday, September 29, 2015 15:10
> *To: *timo.kinnunen at gmail.com 
> <mailto:timo.kinnunen at gmail.com>;valhalla-dev at openjdk.java.net 
> <mailto:valhalla-dev at openjdk.java.net>
> *Subject: *Re: Time to rebase on top of JDK 9 repository?
>
> On 29/09/15 13:58, timo.kinnunen at gmail.com 
> <mailto:timo.kinnunen at gmail.com> wrote:
>
> > Hi,
>
> >
>
> > I?ve been looking into compiling Valhalla with Visual Studio 2015 to 
> try it out but I have hit a snag. See, I have made the needed changes 
> and have a working build but I made the changes on top of the 
> jdk9/jdk9 repository. I tried bringing the changes over to the 
> valhalla/valhalla repository but the valhalla repository seems to be 
> several months behind the JDK 9 repositories. There?s quite a lot of 
> changes missing. Is it time to merge in the latest JDK 9 changes?
>
> >
>
> > I?m not an expert on mercurial nor familiar with the valhalla 
> implementation details so I?m otherwise pretty much stuck.
>
> Yep - I agree it's time to merge - it's on my radar; as a short-term
>
> measure, is there any specific changeset you need pushed in order to get
>
> up and running with VS2015?
>
> Maurizio
>
> >
>
> >
>
> >
>
> > Sent from Mail for Windows 10
>
>
>



From pbenedict at apache.org  Wed Sep 30 14:14:34 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 30 Sep 2015 09:14:34 -0500
Subject: hg: valhalla/valhalla/jdk: First cut at model 3 converter; if we
	detect classfile 52.1 when loading, divert to model 3 rewriter
In-Reply-To: <201509291842.t8TIgZI7008391@aojmv0008.oracle.com>
References: <201509291842.t8TIgZI7008391@aojmv0008.oracle.com>
Message-ID: <CABLGb9wrRwwTHxrp+1=CV_pFY3JskNcoeWs7-kwjhhW9Dqi7tw@mail.gmail.com>

Brian, I watched your video about the Model 1 and Model 2 (mangling?)
approaches. I can't remember if you mentioned a Model 3 approach in your
presentation. My apologies if I forgotten, but can you quickly explain what
makes Model 3 different?


Cheers,
Paul

On Tue, Sep 29, 2015 at 1:42 PM, <brian.goetz at oracle.com> wrote:

> Changeset: bf66aeeef857
> Author:    briangoetz
> Date:      2015-09-29 14:34 -0400
> URL:
> http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bf66aeeef857
>
> First cut at model 3 converter; if we detect classfile 52.1 when loading,
> divert to model 3 rewriter
>
> ! src/java.base/share/classes/java/net/URLClassLoader.java
> + src/java.base/share/classes/valhalla/model3/Model3Converter.java
> + src/java.base/share/classes/valhalla/model3/SpeciesKey.java
>
>


From brian.goetz at oracle.com  Wed Sep 30 14:35:24 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 30 Sep 2015 10:35:24 -0400
Subject: hg: valhalla/valhalla/jdk: First cut at model 3 converter; if we
	detect classfile 52.1 when loading, divert to model 3 rewriter
In-Reply-To: <CABLGb9wrRwwTHxrp+1=CV_pFY3JskNcoeWs7-kwjhhW9Dqi7tw@mail.gmail.com>
References: <201509291842.t8TIgZI7008391@aojmv0008.oracle.com>
	<CABLGb9wrRwwTHxrp+1=CV_pFY3JskNcoeWs7-kwjhhW9Dqi7tw@mail.gmail.com>
Message-ID: <560BF32C.1010708@oracle.com>

Model 3 == Act 3.

On 9/30/2015 10:14 AM, Paul Benedict wrote:
> Brian, I watched your video about the Model 1 and Model 2 (mangling?)
> approaches. I can't remember if you mentioned a Model 3 approach in your
> presentation. My apologies if I forgotten, but can you quickly explain
> what makes Model 3 different?
>
>
> Cheers,
> Paul
>
> On Tue, Sep 29, 2015 at 1:42 PM, <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Changeset: bf66aeeef857
>     Author:    briangoetz
>     Date:      2015-09-29 14:34 -0400
>     URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bf66aeeef857
>
>     First cut at model 3 converter; if we detect classfile 52.1 when
>     loading, divert to model 3 rewriter
>
>     ! src/java.base/share/classes/java/net/URLClassLoader.java
>     + src/java.base/share/classes/valhalla/model3/Model3Converter.java
>     + src/java.base/share/classes/valhalla/model3/SpeciesKey.java
>
>