From martijnverburg at gmail.com  Mon Feb  1 10:39:39 2016
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 1 Feb 2016 10:39:39 +0000
Subject: Monthly notice for new signups to Project Valhalla - How to Contribute
Message-ID: <CAP7YuATsLrY81qiJ=djAZNms5_1F0p+GUt5kBk-ZPX1JAX9+CQ@mail.gmail.com>

Hi all,

Valhalla is one of OpenJDK's more complex areas to get involved in. A guide
to getting started with Valhalla and levels of suggested contribution can
be found on the home page:

http://openjdk.java.net/projects/valhalla/

Cheers,
Martijn

From paul.sandoz at oracle.com  Tue Feb  9 11:12:26 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Feb 2016 12:12:26 +0100
Subject: API review of VarHandles
In-Reply-To: <CAPYFHW25HGYVLN12cvBwVtU-e0OO42tsLALvyUAwuKc_qkVS-g@mail.gmail.com>
References: <9461B198-5706-459C-A6BB-E8282AF9237A@oracle.com>
	<CAPYFHW25HGYVLN12cvBwVtU-e0OO42tsLALvyUAwuKc_qkVS-g@mail.gmail.com>
Message-ID: <4EC42B69-2603-43BC-AB29-BAD8EF53F90E@oracle.com>

Hi Jeremy,

Sorry for the late reply. Catching after some distractions and being away.


> On 22 Jan 2016, at 19:03, Jeremy Manson <jeremymanson at google.com> wrote:
> 
> Couple of thoughts:
> The Java Language Specification permits operations to be executed in orders different than are apparent in program source code, subject to constraints arising, for example, from the use of locks, volatile fields or VarHandles. The static methods, fullFence, acquireFence, releaseFence, loadLoadFence andstoreStoreFence, 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.
> 
> 
> There is no notion of reordering (per se) in the JLS; the fact that reorderings can occur is just implied by the way programs can be observed to behave. So, these fence operations don't map to anything non-implementation dependent.  I don't think it would be impossible to fix the spec to define something that works the way you want (similar to the final field semantics), but it isn't in there already.  You might want to call that out (either by saying this behavior is best effort implementation-dependent or by fixing the spec).
> 

Until we update the JMM spec, pushed out beyond 9, we are in a bit of a bind and have to hand wave a bit for both access mode methods and fences, both of which talk about reorderings (see getAcquire/setRelease for example).

There is the following at the end, but it?s easy to loose sight of with all the other sections:

* @apiNote
* More precise phrasing of the specification of access mode methods and memory
* fence methods may accompany future updates of the Java Language
* Specification.

I moved that up into the fences paragraph.

* <p>In addition to supporting access to variables under various access modes,
* a set of static methods, referred to as memory fence methods, is also
* provided for fine-grained control of memory ordering.
*
* The Java Language Specification permits operations to be executed in
* orders different than are apparent in program source code, subject to
* constraints arising, for example, from the use of locks, {@code volatile}
* fields or VarHandles.  The static methods, {@link #fullFence fullFence},
* {@link #acquireFence acquireFence}, {@link #releaseFence releaseFence},
* {@link #loadLoadFence loadLoadFence} and {@link #storeStoreFence
* storeStoreFence}, can also be used to impose constraints.  Their
* specifications, as is the case for certain access modes, are phrased in terms
* of the lack of "reorderings" -- observable ordering effects that might
* otherwise occur if the fence was not present.  More precise phrasing of the
* specification of access mode methods and memory fence methods may accompany
* future updates of the Java Language Specification.


I could append another sentence:

  Until then, such reordering behaviour is considered implementation-dependent on a best-effort basis.

But perhaps the less we say the better?


> If a VarHandle references a read-only variable (for example a final field) then write, atomic update and numeric atomic update access modes are not supported and corresponding methods throw UnsupportedOperationException.
> 
> Are you sure you want to limit it in this way?  There are an awful lot of calls to setAccessible in the world of reflection.  And writing to final fields *does* map to something sensible in the spec.  In fact, it would be great to have something that wasn't quite such a blunt instrument as setAccessible.

Indeed, very much a blunt instrument.

Note that setAccessible would otherwise be required to be called on the Field before being unreflected (either for unreflectVarHandle or, as is the case today, unreflectSetter/Getter).

I don?t wanna widen the accessibility hole of this blunt instrument right now; it?s easy to widen rather than shrink later on if need be.

The motivation behind this is we want to move towards a world "final really means final" and thus lots of nice optimisations may ensue. It may be a long and windy road to get there but we have some plans and are starting to work some routes towards that goal.


> 
> getVolatile
> public final Object getVolatile(Object... args)
> Returns the value of a variable, with memory semantics of reading a volatile variable.
> 
> Reading *which* volatile variable?  You probably mean that all getVolatiles and setVolatiles provide semantics that behave as if the variable being written / read was declared volatile in the first place, but it is worth calling out.
> 

/**
 * Returns the value of a variable, with memory semantics of reading as if
 * the variable was declared {@code volatile}.
...
Object getVolatile(Object... args);

/**
 * Sets the value of a variable to the {@code newValue}, with memory
 * semantics of setting as if the variable was declared {@code volatile}.
?
void setVolatile(Object... args);

I also updated the plain accessors using similar ?as if? language.


> Nits:
> 

The following nits are copied and translated from documentation on MethodHandle.


> As is usual with virtual methods, source-level calls to access mode methods compile to an invokevirtual instruction. More unusually, the compiler must record the actual argument types, and may not perform method invocation conversions on the arguments. Instead, it must push them on the stack according to their own unconverted types. The VarHandle object itself is pushed on the stack before the arguments. The compiler then calls the VarHandle with a symbolic type descriptor which describes the argument and return types.
> 
> This is somewhat oddly worded.  The compiler doesn't push arguments on a stack or call anything - it generates instructions that do that.
> 

I updated to:

* As is usual with virtual methods, source-level calls to access mode methods
* compile to an {@code invokevirtual} instruction.  More unusually, the
* compiler must record the actual argument types, and may not perform method
* invocation conversions on the arguments.  Instead, it must generate
* instructions to push them on the stack according to their own unconverted
* types.  The VarHandle object itself will be pushed on the stack before the
* arguments.  The compiler then generates an {@code invokevirtual} instruction
* that invokes the access mode method with a symbolic type descriptor which
* describes the argument and return types.


> The first time a invokevirtual instruction is executed it is linked, by symbolically resolving the names in the instruction and verifying that the method call is statically legal
> 
> I keep trying not to call this out as a nit, but there should be no comma between "linked" and "by?.

Updated.

In both cases I also updated the relevant areas in MethodHandle.

Thanks,
Paul.

From jeremymanson at google.com  Wed Feb 10 00:09:06 2016
From: jeremymanson at google.com (Jeremy Manson)
Date: Tue, 9 Feb 2016 16:09:06 -0800
Subject: API review of VarHandles
In-Reply-To: <4EC42B69-2603-43BC-AB29-BAD8EF53F90E@oracle.com>
References: <9461B198-5706-459C-A6BB-E8282AF9237A@oracle.com>
	<CAPYFHW25HGYVLN12cvBwVtU-e0OO42tsLALvyUAwuKc_qkVS-g@mail.gmail.com>
	<4EC42B69-2603-43BC-AB29-BAD8EF53F90E@oracle.com>
Message-ID: <CAPYFHW2PvQkkNAyRw=k5bAtOpqSwFQo4j=4izsEbOUG1frv0fA@mail.gmail.com>

Thanks, Paul!  I agree that the wording about reorderings is probably
okay.  I probably would have added the sentence about
implementation-dependence, but I can see why you might want to avoid it.

Jeremy

On Tue, Feb 9, 2016 at 3:12 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Jeremy,
>
> Sorry for the late reply. Catching after some distractions and being away.
>
>
> > On 22 Jan 2016, at 19:03, Jeremy Manson <jeremymanson at google.com> wrote:
> >
> > Couple of thoughts:
> > The Java Language Specification permits operations to be executed in
> orders different than are apparent in program source code, subject to
> constraints arising, for example, from the use of locks, volatile fields or
> VarHandles. The static methods, fullFence, acquireFence, releaseFence,
> loadLoadFence andstoreStoreFence, 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.
> >
> >
> > There is no notion of reordering (per se) in the JLS; the fact that
> reorderings can occur is just implied by the way programs can be observed
> to behave. So, these fence operations don't map to anything
> non-implementation dependent.  I don't think it would be impossible to fix
> the spec to define something that works the way you want (similar to the
> final field semantics), but it isn't in there already.  You might want to
> call that out (either by saying this behavior is best effort
> implementation-dependent or by fixing the spec).
> >
>
> Until we update the JMM spec, pushed out beyond 9, we are in a bit of a
> bind and have to hand wave a bit for both access mode methods and fences,
> both of which talk about reorderings (see getAcquire/setRelease for
> example).
>
> There is the following at the end, but it?s easy to loose sight of with
> all the other sections:
>
> * @apiNote
> * More precise phrasing of the specification of access mode methods and
> memory
> * fence methods may accompany future updates of the Java Language
> * Specification.
>
> I moved that up into the fences paragraph.
>
> * <p>In addition to supporting access to variables under various access
> modes,
> * a set of static methods, referred to as memory fence methods, is also
> * provided for fine-grained control of memory ordering.
> *
> * The Java Language Specification permits operations to be executed in
> * orders different than are apparent in program source code, subject to
> * constraints arising, for example, from the use of locks, {@code volatile}
> * fields or VarHandles.  The static methods, {@link #fullFence fullFence},
> * {@link #acquireFence acquireFence}, {@link #releaseFence releaseFence},
> * {@link #loadLoadFence loadLoadFence} and {@link #storeStoreFence
> * storeStoreFence}, can also be used to impose constraints.  Their
> * specifications, as is the case for certain access modes, are phrased in
> terms
> * of the lack of "reorderings" -- observable ordering effects that might
> * otherwise occur if the fence was not present.  More precise phrasing of
> the
> * specification of access mode methods and memory fence methods may
> accompany
> * future updates of the Java Language Specification.
>
>
> I could append another sentence:
>
>   Until then, such reordering behaviour is considered
> implementation-dependent on a best-effort basis.
>
> But perhaps the less we say the better?
>
>
> > If a VarHandle references a read-only variable (for example a final
> field) then write, atomic update and numeric atomic update access modes are
> not supported and corresponding methods throw UnsupportedOperationException.
> >
> > Are you sure you want to limit it in this way?  There are an awful lot
> of calls to setAccessible in the world of reflection.  And writing to final
> fields *does* map to something sensible in the spec.  In fact, it would be
> great to have something that wasn't quite such a blunt instrument as
> setAccessible.
>
> Indeed, very much a blunt instrument.
>
> Note that setAccessible would otherwise be required to be called on the
> Field before being unreflected (either for unreflectVarHandle or, as is the
> case today, unreflectSetter/Getter).
>
> I don?t wanna widen the accessibility hole of this blunt instrument right
> now; it?s easy to widen rather than shrink later on if need be.
>
> The motivation behind this is we want to move towards a world "final
> really means final" and thus lots of nice optimisations may ensue. It may
> be a long and windy road to get there but we have some plans and are
> starting to work some routes towards that goal.
>
>
> >
> > getVolatile
> > public final Object getVolatile(Object... args)
> > Returns the value of a variable, with memory semantics of reading a
> volatile variable.
> >
> > Reading *which* volatile variable?  You probably mean that all
> getVolatiles and setVolatiles provide semantics that behave as if the
> variable being written / read was declared volatile in the first place, but
> it is worth calling out.
> >
>
> /**
>  * Returns the value of a variable, with memory semantics of reading as if
>  * the variable was declared {@code volatile}.
> ...
> Object getVolatile(Object... args);
>
> /**
>  * Sets the value of a variable to the {@code newValue}, with memory
>  * semantics of setting as if the variable was declared {@code volatile}.
> ?
> void setVolatile(Object... args);
>
> I also updated the plain accessors using similar ?as if? language.
>
>
> > Nits:
> >
>
> The following nits are copied and translated from documentation on
> MethodHandle.
>
>
> > As is usual with virtual methods, source-level calls to access mode
> methods compile to an invokevirtual instruction. More unusually, the
> compiler must record the actual argument types, and may not perform method
> invocation conversions on the arguments. Instead, it must push them on the
> stack according to their own unconverted types. The VarHandle object itself
> is pushed on the stack before the arguments. The compiler then calls the
> VarHandle with a symbolic type descriptor which describes the argument and
> return types.
> >
> > This is somewhat oddly worded.  The compiler doesn't push arguments on a
> stack or call anything - it generates instructions that do that.
> >
>
> I updated to:
>
> * As is usual with virtual methods, source-level calls to access mode
> methods
> * compile to an {@code invokevirtual} instruction.  More unusually, the
> * compiler must record the actual argument types, and may not perform
> method
> * invocation conversions on the arguments.  Instead, it must generate
> * instructions to push them on the stack according to their own unconverted
> * types.  The VarHandle object itself will be pushed on the stack before
> the
> * arguments.  The compiler then generates an {@code invokevirtual}
> instruction
> * that invokes the access mode method with a symbolic type descriptor which
> * describes the argument and return types.
>
>
> > The first time a invokevirtual instruction is executed it is linked, by
> symbolically resolving the names in the instruction and verifying that the
> method call is statically legal
> >
> > I keep trying not to call this out as a nit, but there should be no
> comma between "linked" and "by?.
>
> Updated.
>
> In both cases I also updated the relevant areas in MethodHandle.
>
> Thanks,
> Paul.
>

From hboehm at google.com  Wed Feb 10 01:03:22 2016
From: hboehm at google.com (Hans Boehm)
Date: Tue, 9 Feb 2016 17:03:22 -0800
Subject: API review of VarHandles
In-Reply-To: <CAPYFHW2PvQkkNAyRw=k5bAtOpqSwFQo4j=4izsEbOUG1frv0fA@mail.gmail.com>
References: <9461B198-5706-459C-A6BB-E8282AF9237A@oracle.com>
	<CAPYFHW25HGYVLN12cvBwVtU-e0OO42tsLALvyUAwuKc_qkVS-g@mail.gmail.com>
	<4EC42B69-2603-43BC-AB29-BAD8EF53F90E@oracle.com>
	<CAPYFHW2PvQkkNAyRw=k5bAtOpqSwFQo4j=4izsEbOUG1frv0fA@mail.gmail.com>
Message-ID: <CAMOCf+i=vW3uQVR5_hiTj4Q++fSGHNxTuCksipzyb=s4gNfQMw@mail.gmail.com>

I found this a bit scary for naive readers:

* The Java Language Specification permits operations to be executed in
* orders different than are apparent in program source code, subject to
* constraints arising, for example, from the use of locks, {@code volatile}
* fields or VarHandles.

I would change it to

* The Java Language Specification permits other threads to observe
operations
* as if they were executed in orders different than are apparent in program
source code,
* subject to constraints arising, for example, from the use of locks,
{@code volatile}
* fields or VarHandles.

to make it clear that we are not talking about intra-thread semantics here.

That way it will hopefully only be scary to experts, as intended.

On Tue, Feb 9, 2016 at 4:09 PM, Jeremy Manson <jeremymanson at google.com>
wrote:

> Thanks, Paul!  I agree that the wording about reorderings is probably
> okay.  I probably would have added the sentence about
> implementation-dependence, but I can see why you might want to avoid it.
>
> Jeremy
>
> On Tue, Feb 9, 2016 at 3:12 AM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
> > Hi Jeremy,
> >
> > Sorry for the late reply. Catching after some distractions and being
> away.
> >
> >
> > > On 22 Jan 2016, at 19:03, Jeremy Manson <jeremymanson at google.com>
> wrote:
> > >
> > > Couple of thoughts:
> > > The Java Language Specification permits operations to be executed in
> > orders different than are apparent in program source code, subject to
> > constraints arising, for example, from the use of locks, volatile fields
> or
> > VarHandles. The static methods, fullFence, acquireFence, releaseFence,
> > loadLoadFence andstoreStoreFence, 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.
> > >
> > >
> > > There is no notion of reordering (per se) in the JLS; the fact that
> > reorderings can occur is just implied by the way programs can be observed
> > to behave. So, these fence operations don't map to anything
> > non-implementation dependent.  I don't think it would be impossible to
> fix
> > the spec to define something that works the way you want (similar to the
> > final field semantics), but it isn't in there already.  You might want to
> > call that out (either by saying this behavior is best effort
> > implementation-dependent or by fixing the spec).
> > >
> >
> > Until we update the JMM spec, pushed out beyond 9, we are in a bit of a
> > bind and have to hand wave a bit for both access mode methods and fences,
> > both of which talk about reorderings (see getAcquire/setRelease for
> > example).
> >
> > There is the following at the end, but it?s easy to loose sight of with
> > all the other sections:
> >
> > * @apiNote
> > * More precise phrasing of the specification of access mode methods and
> > memory
> > * fence methods may accompany future updates of the Java Language
> > * Specification.
> >
> > I moved that up into the fences paragraph.
> >
> > * <p>In addition to supporting access to variables under various access
> > modes,
> > * a set of static methods, referred to as memory fence methods, is also
> > * provided for fine-grained control of memory ordering.
> > *
> > * The Java Language Specification permits operations to be executed in
> > * orders different than are apparent in program source code, subject to
> > * constraints arising, for example, from the use of locks, {@code
> volatile}
> > * fields or VarHandles.  The static methods, {@link #fullFence
> fullFence},
> > * {@link #acquireFence acquireFence}, {@link #releaseFence releaseFence},
> > * {@link #loadLoadFence loadLoadFence} and {@link #storeStoreFence
> > * storeStoreFence}, can also be used to impose constraints.  Their
> > * specifications, as is the case for certain access modes, are phrased in
> > terms
> > * of the lack of "reorderings" -- observable ordering effects that might
> > * otherwise occur if the fence was not present.  More precise phrasing of
> > the
> > * specification of access mode methods and memory fence methods may
> > accompany
> > * future updates of the Java Language Specification.
> >
> >
> > I could append another sentence:
> >
> >   Until then, such reordering behaviour is considered
> > implementation-dependent on a best-effort basis.
> >
> > But perhaps the less we say the better?
> >
> >
> > > If a VarHandle references a read-only variable (for example a final
> > field) then write, atomic update and numeric atomic update access modes
> are
> > not supported and corresponding methods throw
> UnsupportedOperationException.
> > >
> > > Are you sure you want to limit it in this way?  There are an awful lot
> > of calls to setAccessible in the world of reflection.  And writing to
> final
> > fields *does* map to something sensible in the spec.  In fact, it would
> be
> > great to have something that wasn't quite such a blunt instrument as
> > setAccessible.
> >
> > Indeed, very much a blunt instrument.
> >
> > Note that setAccessible would otherwise be required to be called on the
> > Field before being unreflected (either for unreflectVarHandle or, as is
> the
> > case today, unreflectSetter/Getter).
> >
> > I don?t wanna widen the accessibility hole of this blunt instrument right
> > now; it?s easy to widen rather than shrink later on if need be.
> >
> > The motivation behind this is we want to move towards a world "final
> > really means final" and thus lots of nice optimisations may ensue. It may
> > be a long and windy road to get there but we have some plans and are
> > starting to work some routes towards that goal.
> >
> >
> > >
> > > getVolatile
> > > public final Object getVolatile(Object... args)
> > > Returns the value of a variable, with memory semantics of reading a
> > volatile variable.
> > >
> > > Reading *which* volatile variable?  You probably mean that all
> > getVolatiles and setVolatiles provide semantics that behave as if the
> > variable being written / read was declared volatile in the first place,
> but
> > it is worth calling out.
> > >
> >
> > /**
> >  * Returns the value of a variable, with memory semantics of reading as
> if
> >  * the variable was declared {@code volatile}.
> > ...
> > Object getVolatile(Object... args);
> >
> > /**
> >  * Sets the value of a variable to the {@code newValue}, with memory
> >  * semantics of setting as if the variable was declared {@code volatile}.
> > ?
> > void setVolatile(Object... args);
> >
> > I also updated the plain accessors using similar ?as if? language.
> >
> >
> > > Nits:
> > >
> >
> > The following nits are copied and translated from documentation on
> > MethodHandle.
> >
> >
> > > As is usual with virtual methods, source-level calls to access mode
> > methods compile to an invokevirtual instruction. More unusually, the
> > compiler must record the actual argument types, and may not perform
> method
> > invocation conversions on the arguments. Instead, it must push them on
> the
> > stack according to their own unconverted types. The VarHandle object
> itself
> > is pushed on the stack before the arguments. The compiler then calls the
> > VarHandle with a symbolic type descriptor which describes the argument
> and
> > return types.
> > >
> > > This is somewhat oddly worded.  The compiler doesn't push arguments on
> a
> > stack or call anything - it generates instructions that do that.
> > >
> >
> > I updated to:
> >
> > * As is usual with virtual methods, source-level calls to access mode
> > methods
> > * compile to an {@code invokevirtual} instruction.  More unusually, the
> > * compiler must record the actual argument types, and may not perform
> > method
> > * invocation conversions on the arguments.  Instead, it must generate
> > * instructions to push them on the stack according to their own
> unconverted
> > * types.  The VarHandle object itself will be pushed on the stack before
> > the
> > * arguments.  The compiler then generates an {@code invokevirtual}
> > instruction
> > * that invokes the access mode method with a symbolic type descriptor
> which
> > * describes the argument and return types.
> >
> >
> > > The first time a invokevirtual instruction is executed it is linked, by
> > symbolically resolving the names in the instruction and verifying that
> the
> > method call is statically legal
> > >
> > > I keep trying not to call this out as a nit, but there should be no
> > comma between "linked" and "by?.
> >
> > Updated.
> >
> > In both cases I also updated the relevant areas in MethodHandle.
> >
> > Thanks,
> > Paul.
> >
>

From paul.sandoz at oracle.com  Wed Feb 10 09:52:27 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 10 Feb 2016 10:52:27 +0100
Subject: API review of VarHandles
In-Reply-To: <CAMOCf+i=vW3uQVR5_hiTj4Q++fSGHNxTuCksipzyb=s4gNfQMw@mail.gmail.com>
References: <9461B198-5706-459C-A6BB-E8282AF9237A@oracle.com>
	<CAPYFHW25HGYVLN12cvBwVtU-e0OO42tsLALvyUAwuKc_qkVS-g@mail.gmail.com>
	<4EC42B69-2603-43BC-AB29-BAD8EF53F90E@oracle.com>
	<CAPYFHW2PvQkkNAyRw=k5bAtOpqSwFQo4j=4izsEbOUG1frv0fA@mail.gmail.com>
	<CAMOCf+i=vW3uQVR5_hiTj4Q++fSGHNxTuCksipzyb=s4gNfQMw@mail.gmail.com>
Message-ID: <43E1CE7C-A367-4687-BD02-5A9ED39828AE@oracle.com>


> On 10 Feb 2016, at 02:03, Hans Boehm <hboehm at google.com> wrote:
> 
> I found this a bit scary for naive readers:
> 
> * The Java Language Specification permits operations to be executed in
> * orders different than are apparent in program source code, subject to
> * constraints arising, for example, from the use of locks, {@code volatile}
> * fields or VarHandles.
> 
> I would change it to
> 
> * The Java Language Specification permits other threads to observe operations
> * as if they were executed in orders different than are apparent in program source code,
> * subject to constraints arising, for example, from the use of locks, {@code volatile}
> * fields or VarHandles.
> 
> to make it clear that we are not talking about intra-thread semantics here.
> 
> That way it will hopefully only be scary to experts, as intended.
> 

Many thanks! updated to what you suggest,
Paul.

From srikanth.adayapalam at oracle.com  Thu Feb 11 09:15:45 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Thu, 11 Feb 2016 09:15:45 +0000
Subject: hg: valhalla/valhalla/langtools: Summary: Opcodes dup,
	dup2 and swap should not target value types or any type variables.
Message-ID: <201602110915.u1B9Fjxs017809@aojmv0008.oracle.com>

Changeset: 1b3a1239c255
Author:    sadayapalam
Date:      2016-02-11 14:45 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/1b3a1239c255

Summary: Opcodes dup, dup2 and swap should not target value types or any type variables.

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
+ test/tools/javac/valhalla/values/CheckNoDups.java
+ test/tools/javac/valhalla/values/LargeCodeTest.java
+ test/tools/javac/valhalla/values/NoVerifyErrorTest.java


From srikanth.adayapalam at oracle.com  Thu Feb 11 13:25:22 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Thu, 11 Feb 2016 13:25:22 +0000
Subject: hg: valhalla/valhalla/langtools: Summary: Opcode dup_x1 should not
	target value types or any type variables.
Message-ID: <201602111325.u1BDPMi2015275@aojmv0008.oracle.com>

Changeset: ac1d5e333073
Author:    sadayapalam
Date:      2016-02-11 18:55 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ac1d5e333073

Summary: Opcode dup_x1 should not target value types or any type variables.

! 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
! test/tools/javac/valhalla/values/CheckNoDups.java


From srikanth.adayapalam at oracle.com  Fri Feb 12 04:52:11 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Fri, 12 Feb 2016 04:52:11 +0000
Subject: hg: valhalla/valhalla/langtools: Summary: Simplified emission of
	alternate sequence for dup family of opcodes when they target
	value types or any type variables.
Message-ID: <201602120452.u1C4qGAa022462@aojmv0008.oracle.com>

Changeset: db795ec80b8c
Author:    sadayapalam
Date:      2016-02-12 10:21 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/db795ec80b8c

Summary: Simplified emission of alternate sequence for dup family of opcodes when they target value types or any type variables.

! 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 srikanth.adayapalam at oracle.com  Fri Feb 12 07:53:36 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Fri, 12 Feb 2016 07:53:36 +0000
Subject: hg: valhalla/valhalla/langtools: Summary: Opcodes dup_x2 and dup2_x1
	should not target value types or any type variables.
Message-ID: <201602120753.u1C7raVk017637@aojmv0008.oracle.com>

Changeset: 9cedd149b8b7
Author:    sadayapalam
Date:      2016-02-12 13:23 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9cedd149b8b7

Summary: Opcodes dup_x2 and dup2_x1 should not target value types or any type variables.

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
! test/tools/javac/valhalla/values/CheckNoDups.java


From srikanth.adayapalam at oracle.com  Mon Feb 15 06:38:42 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Mon, 15 Feb 2016 06:38:42 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Tree copier should not lose
	valueness of the instantiated entity
Message-ID: <201602150638.u1F6cglJ019368@aojmv0008.oracle.com>

Changeset: f92a3e98fbf7
Author:    sadayapalam
Date:      2016-02-15 12:08 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/f92a3e98fbf7

Fix: Tree copier should not lose valueness of the instantiated entity

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java


From maurizio.cimadamore at oracle.com  Mon Feb 15 12:29:08 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 15 Feb 2016 12:29:08 +0000
Subject: hg: valhalla/valhalla/langtools: Generic classfile fixes:
Message-ID: <201602151229.u1FCT883016016@aojmv0008.oracle.com>

Changeset: 3eeba6c32aa5
Author:    mcimadamore
Date:      2016-02-15 12:28 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3eeba6c32aa5

Generic classfile fixes:
* add step to PoolWriter to avoid generation of new constant pool forms when regular forms are good enough, to minimise incompatibilities
* Various fixes to jdeps so that it works with generic classfiles
* Refined implementation of 'anyrasure' which was leaking type-variables
* Consolidated some routines in Types.java
* added some tests

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Signature.java
+ test/tools/javac/valhalla/typespec/GenericClassFile01.java
+ test/tools/javac/valhalla/typespec/GenericClassFile02.java
+ test/tools/javac/valhalla/typespec/GenericClassFile03.java
+ test/tools/javac/valhalla/typespec/GenericClassFile04.java
+ test/tools/javac/valhalla/typespec/GenericClassFile05.java
+ test/tools/javac/valhalla/typespec/GenericClassFile06.java


From stanislav.smirnov at oracle.com  Tue Feb 16 08:01:19 2016
From: stanislav.smirnov at oracle.com (Stas Smirnov)
Date: Tue, 16 Feb 2016 11:01:19 +0300
Subject: RFR: initial set of tests for nestmates vm exploration
Message-ID: <56C2D74F.4000709@oracle.com>

Hello,

Please review this initial set of tests for nestmates vm exploration. 
This new tests cover basic runtime access checks in down->up direction 
in terms of nested classes and inheritance. There are going to be more 
tests to speedup runtime development of nestmates support.

webrev.00: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.00
Testing: RBT

-- 
Best regards,
Stanislav


From maurizio.cimadamore at oracle.com  Tue Feb 16 10:39:15 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Feb 2016 10:39:15 +0000
Subject: RFR: initial set of tests for nestmates vm exploration
In-Reply-To: <56C2D74F.4000709@oracle.com>
References: <56C2D74F.4000709@oracle.com>
Message-ID: <56C2FC53.7020703@oracle.com>

Looks good; I found few typos i.e. PPRIVATE and pprivate (is that 
deliberate?).

Also, on a more substantial point, these are all positive tests; would 
it make sense to have also some negative tests to verify that:

* you can't get access outside nestmate boundaries (perhaps hard to 
write/compile with javac, but should be doable with reflection)
* private members are not accidentally inherited (again, hard to 
write/compile with javac)

Maurizio

On 16/02/16 08:01, Stas Smirnov wrote:
> Hello,
>
> Please review this initial set of tests for nestmates vm exploration. 
> This new tests cover basic runtime access checks in down->up direction 
> in terms of nested classes and inheritance. There are going to be more 
> tests to speedup runtime development of nestmates support.
>
> webrev.00: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.00
> Testing: RBT
>


From stanislav.smirnov at oracle.com  Tue Feb 16 11:08:11 2016
From: stanislav.smirnov at oracle.com (Stas Smirnov)
Date: Tue, 16 Feb 2016 14:08:11 +0300
Subject: RFR: initial set of tests for nestmates vm exploration
In-Reply-To: <56C2FC53.7020703@oracle.com>
References: <56C2D74F.4000709@oracle.com> <56C2FC53.7020703@oracle.com>
Message-ID: <56C3031B.6060800@oracle.com>

Hi Maurizio,

thanks for you feedback. Please see my comments below

On 16/02/16 13:39, Maurizio Cimadamore wrote:
> Looks good; I found few typos i.e. PPRIVATE and pprivate (is that 
> deliberate?).
pp means package private :) just decided to shorten the long name here
>
> Also, on a more substantial point, these are all positive tests; would 
> it make sense to have also some negative tests to verify that:
>
> * you can't get access outside nestmate boundaries (perhaps hard to 
> write/compile with javac, but should be doable with reflection)
> * private members are not accidentally inherited (again, hard to 
> write/compile with javac)
>
I have it all actually in my list for future test cases, with Karen we 
have decided that it will be a good start to have some general positive 
test cases to cover the basic functionality and all the access 
modifiers, to be able later to focus on the interesting part
like private and protected and the rest test cases base on it.
> Maurizio
>
> On 16/02/16 08:01, Stas Smirnov wrote:
>> Hello,
>>
>> Please review this initial set of tests for nestmates vm exploration. 
>> This new tests cover basic runtime access checks in down->up 
>> direction in terms of nested classes and inheritance. There are going 
>> to be more tests to speedup runtime development of nestmates support.
>>
>> webrev.00: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.00
>> Testing: RBT
>>
>

-- 
Best regards,
Stanislav


From maurizio.cimadamore at oracle.com  Tue Feb 16 14:09:45 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 16 Feb 2016 14:09:45 +0000
Subject: hg: valhalla/valhalla/langtools: More generic classfile fixes:
Message-ID: <201602161409.u1GE9jEM009305@aojmv0008.oracle.com>

Changeset: 884358077731
Author:    mcimadamore
Date:      2016-02-16 14:09 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/884358077731

More generic classfile fixes:
* PoolWriter should not generate genertic entries for virtualized types
* temporarily disable generation of virtualized generic members

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java


From maurizio.cimadamore at oracle.com  Tue Feb 16 14:13:12 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 16 Feb 2016 14:13:12 +0000
Subject: hg: valhalla/valhalla/jdk: Fix: add support for qualified class names
	in Model3Converter
Message-ID: <201602161413.u1GEDCac010709@aojmv0008.oracle.com>

Changeset: a1be3d1ac4e3
Author:    mcimadamore
Date:      2016-02-16 14:12 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a1be3d1ac4e3

Fix: add support for qualified class names in Model3Converter

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


From brian.goetz at oracle.com  Wed Feb 17 20:01:32 2016
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Wed, 17 Feb 2016 20:01:32 +0000
Subject: hg: valhalla/valhalla/jdk: Cleanups in M3 classloader support;
	prepare for bootloader support
Message-ID: <201602172001.u1HK1WOt024704@aojmv0008.oracle.com>

Changeset: fb82bc94a65d
Author:    briangoetz
Date:      2016-02-17 15:01 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fb82bc94a65d

Cleanups in M3 classloader support; prepare for bootloader support

! src/java.base/share/classes/java/net/URLClassLoader.java
! src/java.base/share/classes/sun/misc/URLClassPath.java
! src/java.base/share/classes/valhalla/classdyn/ClassDynHelper.java
! src/java.base/share/classes/valhalla/model3/Model3Converter.java


From maurizio.cimadamore at oracle.com  Thu Feb 18 12:39:19 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 18 Feb 2016 12:39:19 +0000
Subject: hg: valhalla/valhalla/langtools: Add internal switch '-XDemitTyped'
	to force emission of 'typed' opcode
Message-ID: <201602181239.u1ICdJgI027264@aojmv0008.oracle.com>

Changeset: cc1999c46d7b
Author:    mcimadamore
Date:      2016-02-18 12:38 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/cc1999c46d7b

Add internal switch '-XDemitTyped' to force emission of 'typed' opcode
The new switch will rewrite load and store opcodes targeting int/long/double to use the typed opcode.
Example:

class Test {
   void test() {
       int i = 1;
       int b = i;
   }
}

This generates the following bytecode:

void test();
    descriptor: ()V
    flags:
    Code:
      stack=1, locals=3, args_size=1
         0: iconst_1
         1: typed         #7                  // Utf8 I
         4: astore_1
         5: typed         #7                  // Utf8 I
         8: aload_1
         9: typed         #7                  // Utf8 I
        12: astore_2
        13: return

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


From maurizio.cimadamore at oracle.com  Thu Feb 18 14:47:19 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 18 Feb 2016 14:47:19 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: experimental change in
	virtualized interface membership is causing failures in JDK tests
Message-ID: <201602181447.u1IElKSU008624@aojmv0008.oracle.com>

Changeset: 341c9546fee0
Author:    mcimadamore
Date:      2016-02-18 14:47 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/341c9546fee0

Fix: experimental change in virtualized interface membership is causing failures in JDK tests

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java


From david.simms at oracle.com  Fri Feb 19 10:42:27 2016
From: david.simms at oracle.com (david.simms at oracle.com)
Date: Fri, 19 Feb 2016 10:42:27 +0000
Subject: hg: valhalla/valhalla/hotspot: Initial set of tests for runtime
	nestmates prototyping
Message-ID: <201602191042.u1JAgRpc016518@aojmv0008.oracle.com>

Changeset: 59320ce74c12
Author:    stsmirno <stanislav.smirnov at oracle.com>
Date:      2016-02-16 15:06 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/59320ce74c12

Initial set of tests for runtime nestmates prototyping

+ test/runtime/valhalla/nestmates/InnerClassesTest.java
+ test/runtime/valhalla/nestmates/ParentChildTest.java
+ test/runtime/valhalla/nestmates/p1/Sup.java
+ test/runtime/valhalla/nestmates/p2/InnerClassesHolder.java
+ test/runtime/valhalla/nestmates/p2/SubTop.java


From brian.goetz at oracle.com  Fri Feb 19 23:15:01 2016
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 19 Feb 2016 23:15:01 +0000
Subject: hg: valhalla/valhalla/hotspot: Add upcall from boot class loader to
	rewriter for Model 3 classfiles
Message-ID: <201602192315.u1JNF1FR002114@aojmv0008.oracle.com>

Changeset: dfa62de886c1
Author:    briangoetz
Date:      2016-02-19 18:01 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dfa62de886c1

Add upcall from boot class loader to rewriter for Model 3 classfiles

! src/share/vm/classfile/classFileStream.cpp
! src/share/vm/classfile/classFileStream.hpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/vmSymbols.hpp


From srikanth.adayapalam at oracle.com  Mon Feb 22 13:24:56 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Mon, 22 Feb 2016 13:24:56 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: Initial implementation
	and support for invokedirect opcode
Message-ID: <201602221324.u1MDOuLC016714@aojmv0008.oracle.com>

Changeset: bc06342a0481
Author:    sadayapalam
Date:      2016-02-22 18:54 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bc06342a0481

Enhancement: Initial implementation and support for invokedirect opcode

! 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/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java
+ test/tools/javac/valhalla/values/CheckInvokeDirect.java


From maurizio.cimadamore at oracle.com  Mon Feb 22 15:47:11 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 22 Feb 2016 15:47:11 +0000
Subject: hg: valhalla/valhalla/jdk: Fix: catch CNFE in ClassDynHelper
Message-ID: <201602221547.u1MFlCr2019738@aojmv0008.oracle.com>

Changeset: 85f81e27f6d3
Author:    mcimadamore
Date:      2016-02-22 15:46 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/85f81e27f6d3

Fix: catch CNFE in ClassDynHelper
Fix: revert URLClassLoader to use ByteResource

! src/java.base/share/classes/java/net/URLClassLoader.java
! src/java.base/share/classes/valhalla/classdyn/ClassDynHelper.java


From srikanth.adayapalam at oracle.com  Tue Feb 23 04:36:51 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Tue, 23 Feb 2016 04:36:51 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Synthesized java.lang.__Value
	type is not flagged as a value type.
Message-ID: <201602230437.u1N4axHA022288@aojmv0008.oracle.com>

Changeset: 863048d7a463
Author:    sadayapalam
Date:      2016-02-23 10:06 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/863048d7a463

Fix: Synthesized java.lang.__Value type is not flagged as a value type.

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java


From forax at univ-mlv.fr  Tue Feb 23 19:50:25 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 23 Feb 2016 20:50:25 +0100 (CET)
Subject: hg: valhalla/valhalla/langtools: Fix: Synthesized
	java.lang.__Value	type is not flagged as a value type.
In-Reply-To: <201602230437.u1N4axHA022288@aojmv0008.oracle.com>
References: <201602230437.u1N4axHA022288@aojmv0008.oracle.com>
Message-ID: <688150165.1019211.1456257025955.JavaMail.zimbra@u-pem.fr>

Hi Srikanth,
i'm not sure it's a good idea to do that,
__Value is not a value type per se, as java.lang.Enum is not an enum.

R?mi

----- Mail original -----
> De: "srikanth adayapalam" <srikanth.adayapalam at oracle.com>
> ?: valhalla-dev at openjdk.java.net
> Envoy?: Mardi 23 F?vrier 2016 05:36:51
> Objet: hg: valhalla/valhalla/langtools: Fix: Synthesized java.lang.__Value	type is not flagged as a value type.
> 
> Changeset: 863048d7a463
> Author:    sadayapalam
> Date:      2016-02-23 10:06 +0530
> URL:
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/863048d7a463
> 
> Fix: Synthesized java.lang.__Value type is not flagged as a value type.
> 
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
> 
> 

From forax at univ-mlv.fr  Tue Feb 23 20:53:40 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 23 Feb 2016 21:53:40 +0100 (CET)
Subject: hg: valhalla/valhalla/langtools: Enhancement: Initial
	implementation	and support for invokedirect opcode
In-Reply-To: <201602221324.u1MDOuLC016714@aojmv0008.oracle.com>
References: <201602221324.u1MDOuLC016714@aojmv0008.oracle.com>
Message-ID: <123215608.1055825.1456260820240.JavaMail.zimbra@u-pem.fr>

Hi all,
"invokedirect" already exists in the Android realm with a semantics similar to invokespecial,
can it be named "invokevalue" (as invokeinterface) or vinvoke (as vgetfield) ?

regards,
R?mi

----- Mail original -----
> De: "srikanth adayapalam" <srikanth.adayapalam at oracle.com>
> ?: valhalla-dev at openjdk.java.net
> Envoy?: Lundi 22 F?vrier 2016 14:24:56
> Objet: hg: valhalla/valhalla/langtools: Enhancement: Initial implementation	and support for invokedirect opcode
> 
> Changeset: bc06342a0481
> Author:    sadayapalam
> Date:      2016-02-22 18:54 +0530
> URL:
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bc06342a0481
> 
> Enhancement: Initial implementation and support for invokedirect opcode
> 
> ! 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/Gen.java
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
> ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java
> + test/tools/javac/valhalla/values/CheckInvokeDirect.java
> 
> 

From srikanth.adayapalam at oracle.com  Wed Feb 24 04:03:08 2016
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Wed, 24 Feb 2016 09:33:08 +0530
Subject: hg: valhalla/valhalla/langtools: Enhancement: Initial
	implementation and support for invokedirect opcode
In-Reply-To: <123215608.1055825.1456260820240.JavaMail.zimbra@u-pem.fr>
References: <201602221324.u1MDOuLC016714@aojmv0008.oracle.com>
	<123215608.1055825.1456260820240.JavaMail.zimbra@u-pem.fr>
Message-ID: <56CD2B7C.2090208@oracle.com>



On Wednesday 24 February 2016 02:23 AM, Remi Forax wrote:
> Hi all,
> "invokedirect" already exists in the Android realm with a semantics similar to invokespecial,
> can it be named "invokevalue" (as invokeinterface) or vinvoke (as vgetfield) ?

Thanks for the feedback - Based on the feedback from the draft specification
owner (on vacation this week per my understanding), I will follow up 
suitably.

Srikanth

> regards,
> R?mi
>
> ----- Mail original -----
>> De: "srikanth adayapalam" <srikanth.adayapalam at oracle.com>
>> ?: valhalla-dev at openjdk.java.net
>> Envoy?: Lundi 22 F?vrier 2016 14:24:56
>> Objet: hg: valhalla/valhalla/langtools: Enhancement: Initial implementation	and support for invokedirect opcode
>>
>> Changeset: bc06342a0481
>> Author:    sadayapalam
>> Date:      2016-02-22 18:54 +0530
>> URL:
>> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bc06342a0481
>>
>> Enhancement: Initial implementation and support for invokedirect opcode
>>
>> ! 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/Gen.java
>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
>> ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java
>> + test/tools/javac/valhalla/values/CheckInvokeDirect.java
>>
>>


From srikanth.adayapalam at oracle.com  Wed Feb 24 05:40:22 2016
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Wed, 24 Feb 2016 11:10:22 +0530
Subject: hg: valhalla/valhalla/langtools: Fix: Synthesized
	java.lang.__Value type is not flagged as a value type.
In-Reply-To: <688150165.1019211.1456257025955.JavaMail.zimbra@u-pem.fr>
References: <201602230437.u1N4axHA022288@aojmv0008.oracle.com>
	<688150165.1019211.1456257025955.JavaMail.zimbra@u-pem.fr>
Message-ID: <56CD4246.9040207@oracle.com>



On Wednesday 24 February 2016 01:20 AM, Remi Forax wrote:
> Hi Srikanth,
> i'm not sure it's a good idea to do that,
> __Value is not a value type per se, as java.lang.Enum is not an enum.

Hello R?mi,

Thanks for your feedback.

Quite a few things in this area are in flux.

See that the patch we are talking about concerns - as the name of the
method 
(com.sun.tools.javac.code.Symtab#synthesizeJavaLangValueClassIfMissing)
indicates - what javac should do when it does *not* find java.lang.__Value.

When it does find it properly in 
valhalla/jdk/src/java.base/share/classes/java/lang/__Value.java
see that the compiler will see the source file (or the equivalent class 
file) that has a class
declaration header that reads:

__ByValue final public class __Value {
...
}

This class is tagged as a value class as well as is final which is 
problematic.
So the patch is at worst ensuring consistent treatment in an error scenario
as in a normal scenario.

The most pressing need for the change was that in the absence of it, javac
can generate code for a value type constructor that uses aload0 instead 
vload 0
for example in:

public final __ByValue class X {
    X() {
        System.out.println("X::X");
    }
}

   X();
     Code:
        0: aload_0
        1: invokespecial #6                  // Method 
java/lang/__Value."<init>":()V

instead of

    Code:
        0: vload         0
        2: invokespecial #6                  // Method 
java/lang/__Value."<init>":()V

This is causing problems for me in another experiment I am working on.

Long story short, I agree this is something we need to watch for and 
decide what
is the right thing to do.

Thanks!
Srikanth




>
> R?mi
>
> ----- Mail original -----
>> De: "srikanth adayapalam" <srikanth.adayapalam at oracle.com>
>> ?: valhalla-dev at openjdk.java.net
>> Envoy?: Mardi 23 F?vrier 2016 05:36:51
>> Objet: hg: valhalla/valhalla/langtools: Fix: Synthesized java.lang.__Value	type is not flagged as a value type.
>>
>> Changeset: 863048d7a463
>> Author:    sadayapalam
>> Date:      2016-02-23 10:06 +0530
>> URL:
>> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/863048d7a463
>>
>> Fix: Synthesized java.lang.__Value type is not flagged as a value type.
>>
>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
>>
>>


From maurizio.cimadamore at oracle.com  Wed Feb 24 12:46:05 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 24 Feb 2016 12:46:05 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: emit 'typed' on 'anewarray'
	when generic classfile is enabled
Message-ID: <201602241246.u1OCk5Oj015865@aojmv0008.oracle.com>

Changeset: ee263f5c87fb
Author:    mcimadamore
Date:      2016-02-24 12:45 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ee263f5c87fb

Fix: emit 'typed' on 'anewarray' when generic classfile is enabled
Fix: do not propagate name function in generic type factory in PoolWriter
Fix: emit full generic info for stack map verification info when generic classfile is enabled

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


From maurizio.cimadamore at oracle.com  Wed Feb 24 12:46:58 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 24 Feb 2016 12:46:58 +0000
Subject: hg: valhalla/valhalla/jdk: Fix: add M3 support for typed
	astore/astore_n
Message-ID: <201602241246.u1OCkwfj016143@aojmv0008.oracle.com>

Changeset: 885ff86a82a6
Author:    mcimadamore
Date:      2016-02-24 12:46 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/885ff86a82a6

Fix: add M3 support for typed astore/astore_n
Fix: add M3 support for typed anewarray
Fix: add M3 support for StackMap mangling

! src/java.base/share/classes/valhalla/model3/Model3Converter.java
! src/java.base/share/classes/valhalla/model3/classfile/Code_attribute.java
! src/java.base/share/classes/valhalla/model3/classfile/StackMapTable_attribute.java


From stanislav.smirnov at oracle.com  Thu Feb 25 13:12:45 2016
From: stanislav.smirnov at oracle.com (Stas Smirnov)
Date: Thu, 25 Feb 2016 16:12:45 +0300
Subject: RFR: nestmates and methodhandles
Message-ID: <56CEFDCD.50700@oracle.com>

Hello,

please review this set of tests to verify "parent-child" access using 
MethodHandle in terms of nestmates vm exploration.
1. MethodHandleSubTop class contains methods to verify private/protected 
methods/fields of the "super" class using MethodHandle from a single one 
and double level of nesting using access static bridges and direct 
access in negative and positive test cases
2. MethodHandleInheritTest executes a number of positive and negative 
test cases using MethodHandleSubTop methods
it will allow us to verify current implementation and future, when 
access bridges will be removed and MethodHandle access checks will be 
modified.

webrev: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.01
Testing: RBT

-- 
Best regards,
Stanislav


From brian.goetz at oracle.com  Thu Feb 25 14:39:52 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 25 Feb 2016 09:39:52 -0500
Subject: RFR: nestmates and methodhandles
In-Reply-To: <56CEFDCD.50700@oracle.com>
References: <56CEFDCD.50700@oracle.com>
Message-ID: <56CF1238.9030607@oracle.com>

Can I suggest doing this in TestNG?  You'll be far more productive -- 
and failures are easier to debug.  You can use sophisticated asserts 
rather than just comparing to a golden file.  jtreg already supports 
TestNG tests.

For example, each of the negative tests (try-catch-assert expected) can 
be its own test method, and TestNG has a way to mark a test method as 
expected to throw an exception.  So these could be written:

     @Test(expectedExceptions = ClassNotFoundException.class)
     public void testProtectedMethodNeg() {
         inner.getSuperMethodMH(METHOD_NAME_PROTECTED);
     }

It's far more clear what's going on, and each one is its own test case, 
meaning that you can pinpoint a failure more easily.

Happy to help you get up to speed on TestNG if that helps.

On 2/25/2016 8:12 AM, Stas Smirnov wrote:
> Hello,
>
> please review this set of tests to verify "parent-child" access using 
> MethodHandle in terms of nestmates vm exploration.
> 1. MethodHandleSubTop class contains methods to verify 
> private/protected methods/fields of the "super" class using 
> MethodHandle from a single one and double level of nesting using 
> access static bridges and direct access in negative and positive test 
> cases
> 2. MethodHandleInheritTest executes a number of positive and negative 
> test cases using MethodHandleSubTop methods
> it will allow us to verify current implementation and future, when 
> access bridges will be removed and MethodHandle access checks will be 
> modified.
>
> webrev: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.01
> Testing: RBT
>


From maurizio.cimadamore at oracle.com  Thu Feb 25 15:39:47 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 25 Feb 2016 15:39:47 +0000
Subject: RFR: nestmates and methodhandles
In-Reply-To: <56CF1238.9030607@oracle.com>
References: <56CEFDCD.50700@oracle.com> <56CF1238.9030607@oracle.com>
Message-ID: <56CF2043.6080109@oracle.com>

Or, at least, code duplication can be reduced by using a lambda-friendly 
method could be used for testing:

void check(Runnable r, Class<? extends Exception> exClass) {
    try {
       r.run();
    } catch (Exception ex) {
       Asserts.assertEquals(exClass, ex);
    }
}

which you can run as follows:

check(() -> inner.getSuperMethodMH(METHOD_NAME_PROTECTED), 
NoSuchMethodException.class);

Maurizio

On 25/02/16 14:39, Brian Goetz wrote:
> Can I suggest doing this in TestNG?  You'll be far more productive -- 
> and failures are easier to debug.  You can use sophisticated asserts 
> rather than just comparing to a golden file.  jtreg already supports 
> TestNG tests.
>
> For example, each of the negative tests (try-catch-assert expected) 
> can be its own test method, and TestNG has a way to mark a test method 
> as expected to throw an exception.  So these could be written:
>
>     @Test(expectedExceptions = ClassNotFoundException.class)
>     public void testProtectedMethodNeg() {
>         inner.getSuperMethodMH(METHOD_NAME_PROTECTED);
>     }
>
> It's far more clear what's going on, and each one is its own test 
> case, meaning that you can pinpoint a failure more easily.
>
> Happy to help you get up to speed on TestNG if that helps.
>
> On 2/25/2016 8:12 AM, Stas Smirnov wrote:
>> Hello,
>>
>> please review this set of tests to verify "parent-child" access using 
>> MethodHandle in terms of nestmates vm exploration.
>> 1. MethodHandleSubTop class contains methods to verify 
>> private/protected methods/fields of the "super" class using 
>> MethodHandle from a single one and double level of nesting using 
>> access static bridges and direct access in negative and positive test 
>> cases
>> 2. MethodHandleInheritTest executes a number of positive and negative 
>> test cases using MethodHandleSubTop methods
>> it will allow us to verify current implementation and future, when 
>> access bridges will be removed and MethodHandle access checks will be 
>> modified.
>>
>> webrev: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.01
>> Testing: RBT
>>
>


From stanislav.smirnov at oracle.com  Thu Feb 25 17:24:59 2016
From: stanislav.smirnov at oracle.com (Stas Smirnov)
Date: Thu, 25 Feb 2016 20:24:59 +0300
Subject: RFR: nestmates and methodhandles
In-Reply-To: <56CF2043.6080109@oracle.com>
References: <56CEFDCD.50700@oracle.com> <56CF1238.9030607@oracle.com>
	<56CF2043.6080109@oracle.com>
Message-ID: <56CF38EB.7010805@oracle.com>

Bria, Maurizio,

thanks for you feedback.
Brian, good catch, let me take a closer look on TestNG, originally for 
me TestNG was good in terms of generating presets of data, but probably 
it is applicable here as well to unities the test cases.

Maurizio, thanks for you suggestion, but since the target method throws 
an exception, invocation of 
inner.getSuperMethodMH(METHOD_NAME_PROTECTED) must be surrounded with 
try-catch block, no? and in this case it does not make much sense

On 25/02/16 18:39, Maurizio Cimadamore wrote:
> Or, at least, code duplication can be reduced by using a 
> lambda-friendly method could be used for testing:
>
> void check(Runnable r, Class<? extends Exception> exClass) {
>    try {
>       r.run();
>    } catch (Exception ex) {
>       Asserts.assertEquals(exClass, ex);
>    }
> }
>
> which you can run as follows:
>
> check(() -> inner.getSuperMethodMH(METHOD_NAME_PROTECTED), 
> NoSuchMethodException.class);
>
> Maurizio
>
> On 25/02/16 14:39, Brian Goetz wrote:
>> Can I suggest doing this in TestNG? You'll be far more productive -- 
>> and failures are easier to debug.  You can use sophisticated asserts 
>> rather than just comparing to a golden file.  jtreg already supports 
>> TestNG tests.
>>
>> For example, each of the negative tests (try-catch-assert expected) 
>> can be its own test method, and TestNG has a way to mark a test 
>> method as expected to throw an exception.  So these could be written:
>>
>>     @Test(expectedExceptions = ClassNotFoundException.class)
>>     public void testProtectedMethodNeg() {
>>         inner.getSuperMethodMH(METHOD_NAME_PROTECTED);
>>     }
>>
>> It's far more clear what's going on, and each one is its own test 
>> case, meaning that you can pinpoint a failure more easily.
>>
>> Happy to help you get up to speed on TestNG if that helps.
>>
>> On 2/25/2016 8:12 AM, Stas Smirnov wrote:
>>> Hello,
>>>
>>> please review this set of tests to verify "parent-child" access 
>>> using MethodHandle in terms of nestmates vm exploration.
>>> 1. MethodHandleSubTop class contains methods to verify 
>>> private/protected methods/fields of the "super" class using 
>>> MethodHandle from a single one and double level of nesting using 
>>> access static bridges and direct access in negative and positive 
>>> test cases
>>> 2. MethodHandleInheritTest executes a number of positive and 
>>> negative test cases using MethodHandleSubTop methods
>>> it will allow us to verify current implementation and future, when 
>>> access bridges will be removed and MethodHandle access checks will 
>>> be modified.
>>>
>>> webrev: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.01
>>> Testing: RBT
>>>
>>
>

-- 
Best regards,
Stanislav


From rschmitt at pobox.com  Thu Feb 25 17:49:14 2016
From: rschmitt at pobox.com (Ryan Schmitt)
Date: Thu, 25 Feb 2016 09:49:14 -0800
Subject: RFR: nestmates and methodhandles
In-Reply-To: <56CF1238.9030607@oracle.com>
References: <56CEFDCD.50700@oracle.com>
	<56CF1238.9030607@oracle.com>
Message-ID: <CABz7JBNAZGLQrVZ_m3RBY=nnfxesEm9x1oMz9aWgL9hEVRF1mg@mail.gmail.com>

If you're using a recent TestNG, just call Assert#assertThrows. Or, if you
want the thrown exception back, call Assert#expectThrows. These methods
work even with checked exceptions, and they allow you to be much more
specific (compared to expectedExceptions) about where exactly the exception
is supposed to come from, which helps prevent false positives in tests.

On Thu, Feb 25, 2016 at 6:39 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Can I suggest doing this in TestNG?  You'll be far more productive -- and
> failures are easier to debug.  You can use sophisticated asserts rather
> than just comparing to a golden file.  jtreg already supports TestNG tests.
>
> For example, each of the negative tests (try-catch-assert expected) can be
> its own test method, and TestNG has a way to mark a test method as expected
> to throw an exception.  So these could be written:
>
>     @Test(expectedExceptions = ClassNotFoundException.class)
>     public void testProtectedMethodNeg() {
>         inner.getSuperMethodMH(METHOD_NAME_PROTECTED);
>     }
>
> It's far more clear what's going on, and each one is its own test case,
> meaning that you can pinpoint a failure more easily.
>
> Happy to help you get up to speed on TestNG if that helps.
>
>
> On 2/25/2016 8:12 AM, Stas Smirnov wrote:
>
>> Hello,
>>
>> please review this set of tests to verify "parent-child" access using
>> MethodHandle in terms of nestmates vm exploration.
>> 1. MethodHandleSubTop class contains methods to verify private/protected
>> methods/fields of the "super" class using MethodHandle from a single one
>> and double level of nesting using access static bridges and direct access
>> in negative and positive test cases
>> 2. MethodHandleInheritTest executes a number of positive and negative
>> test cases using MethodHandleSubTop methods
>> it will allow us to verify current implementation and future, when access
>> bridges will be removed and MethodHandle access checks will be modified.
>>
>> webrev: http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.01
>> Testing: RBT
>>
>>
>

From maurizio.cimadamore at oracle.com  Thu Feb 25 19:00:08 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 25 Feb 2016 19:00:08 +0000
Subject: RFR: nestmates and methodhandles
In-Reply-To: <56CF38EB.7010805@oracle.com>
References: <56CEFDCD.50700@oracle.com> <56CF1238.9030607@oracle.com>
	<56CF2043.6080109@oracle.com> <56CF38EB.7010805@oracle.com>
Message-ID: <56CF4F38.5030303@oracle.com>



On 25/02/16 17:24, Stas Smirnov wrote:
> Maurizio, thanks for you suggestion, but since the target method 
> throws an exception, invocation of 
> inner.getSuperMethodMH(METHOD_NAME_PROTECTED) must be surrounded with 
> try-catch block, no? and in this case it does not make much sense
If you use Runnable as a target, yes - but you could use a different 
functional interface which is allowed to throw (AutoCloseable could be 
one already made).

Maurizio

From brian.goetz at oracle.com  Fri Feb 26 21:03:01 2016
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 26 Feb 2016 21:03:01 +0000
Subject: hg: valhalla/valhalla/jdk: Tweak to model 3 converter to generate a
	variable set of specializations
Message-ID: <201602262103.u1QL32Zk007513@aojmv0008.oracle.com>

Changeset: fe277517fdbe
Author:    briangoetz
Date:      2016-02-26 16:02 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fe277517fdbe

Tweak to model 3 converter to generate a variable set of specializations

! src/java.base/share/classes/valhalla/model3/Model3Converter.java


From scolebourne at joda.org  Mon Feb 29 00:04:47 2016
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 29 Feb 2016 00:04:47 +0000
Subject: Model 3 Classfile Enhancements question
Message-ID: <CACzrW9A0kh1RWBTqZjLG7wEwuL=yKra6drjca3bnY6A+Ga9LpQ@mail.gmail.com>

The document and following discussion is interesting, however I still
have a question:

This type
 List<Optional<int>>
maps to
 ParameterizedType['L', "List", ParameterizedType['Q', "Optional", "I"]]

but what does this type map to?

 List<Optional<String>>

In other words, is the "String" erased or reified. (If Optional was a
reference type, then it is obviously erased, but since Optional is a
value type in the document, the answer is not clear).

Stephen

From brian.goetz at oracle.com  Mon Feb 29 00:11:55 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 28 Feb 2016 19:11:55 -0500
Subject: Model 3 Classfile Enhancements question
In-Reply-To: <CACzrW9A0kh1RWBTqZjLG7wEwuL=yKra6drjca3bnY6A+Ga9LpQ@mail.gmail.com>
References: <CACzrW9A0kh1RWBTqZjLG7wEwuL=yKra6drjca3bnY6A+Ga9LpQ@mail.gmail.com>
Message-ID: <BDFDAD5A-8E17-49E5-B052-C08BCE8D1ABB@oracle.com>

Assuming Optional<any T> is a value type, it corresponds to:

    ParamType[LList, ParamType[QOptional, erased]]

Reference types as type arguments are always erased, whether they are arguments to a reference or value type.  So the above corresponds to ?reified List of erased Optional.?  

The construction is compositional.  We construct the description of the inner type (ParamType[QOptional, erased]), and then we either reify that or erase it depending on whether the result is reference or value. 

On Feb 28, 2016, at 7:04 PM, Stephen Colebourne <scolebourne at joda.org> wrote:

> The document and following discussion is interesting, however I still
> have a question:
> 
> This type
> List<Optional<int>>
> maps to
> ParameterizedType['L', "List", ParameterizedType['Q', "Optional", "I"]]
> 
> but what does this type map to?
> 
> List<Optional<String>>
> 
> In other words, is the "String" erased or reified. (If Optional was a
> reference type, then it is obviously erased, but since Optional is a
> value type in the document, the answer is not clear).
> 
> Stephen


From srikanth.adayapalam at oracle.com  Mon Feb 29 07:16:14 2016
From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com)
Date: Mon, 29 Feb 2016 07:16:14 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Synthesized java.lang.__Value
	type is not flagged as a value type.
Message-ID: <201602290716.u1T7GESe024012@aojmv0008.oracle.com>

Changeset: 2a7cae3ea93d
Author:    sadayapalam
Date:      2016-02-29 12:44 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2a7cae3ea93d

Fix: Synthesized java.lang.__Value type is not flagged as a value type.

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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
! test/tools/javac/valhalla/values/CheckNoDups.java
+ test/tools/javac/valhalla/values/CheckValueBufferOptimizations.java
+ test/tools/javac/valhalla/values/CheckValueBuffers.java
+ test/tools/javac/valhalla/values/CheckValueBuffersAny.java
+ test/tools/javac/valhalla/values/CheckValueBuffersGenCond.java
+ test/tools/javac/valhalla/values/CheckValueBuffersGenExpr.java
+ test/tools/javac/valhalla/values/CheckValueBuffersVmTest.java


From srikanth.adayapalam at oracle.com  Mon Feb 29 07:27:01 2016
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 29 Feb 2016 12:57:01 +0530
Subject: hg: valhalla/valhalla/langtools: Fix: Synthesized
	java.lang.__Value type is not flagged as a value type.
In-Reply-To: <201602290716.u1T7GESe024012@aojmv0008.oracle.com>
References: <201602290716.u1T7GESe024012@aojmv0008.oracle.com>
Message-ID: <56D3F2C5.3010101@oracle.com>



On Monday 29 February 2016 12:46 PM, srikanth.adayapalam at oracle.com wrote:
> Changeset: 2a7cae3ea93d
> Author:    sadayapalam
> Date:      2016-02-29 12:44 +0530
> URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2a7cae3ea93d
>
> Fix: Synthesized java.lang.__Value type is not flagged as a value type.

Grrr. That should read:

Enhancement: Add initial support for explicitly managed thread local 
backing buffers for values and 'any' operands under the 
-XDenableValueBuffers option.

(the patch contents are as intended, just the summary commit message is 
stale.)

I am exploring what remedial steps are required.

Sorry for the trouble.
Thanks!
Srikanth

>
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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
> ! test/tools/javac/valhalla/values/CheckNoDups.java
> + test/tools/javac/valhalla/values/CheckValueBufferOptimizations.java
> + test/tools/javac/valhalla/values/CheckValueBuffers.java
> + test/tools/javac/valhalla/values/CheckValueBuffersAny.java
> + test/tools/javac/valhalla/values/CheckValueBuffersGenCond.java
> + test/tools/javac/valhalla/values/CheckValueBuffersGenExpr.java
> + test/tools/javac/valhalla/values/CheckValueBuffersVmTest.java
>


From maurizio.cimadamore at oracle.com  Mon Feb 29 15:28:58 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 29 Feb 2016 15:28:58 +0000
Subject: hg: valhalla/valhalla/langtools: Misc M3 fixes:
Message-ID: <201602291528.u1TFSwVc011138@aojmv0008.oracle.com>

Changeset: 241b088a0664
Author:    mcimadamore
Date:      2016-02-29 15:24 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/241b088a0664

Misc M3 fixes:
* type-arguments in generic specializable calls should not be plain Strings
* MethodHandle/MethodType constants are not specialized correctly because of missing type info
* Tweak support for 'Where' attribute when -XDgenericClassFile is enabled
* Missing erasure in code generated by Lower for handling assertion state
* include empty TypeVariableMap layers when generating M3 classfiles

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java


From maurizio.cimadamore at oracle.com  Mon Feb 29 15:31:06 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 29 Feb 2016 15:31:06 +0000
Subject: hg: valhalla/valhalla/jdk: 2 new changesets
Message-ID: <201602291531.u1TFV6Jp012256@aojmv0008.oracle.com>

Changeset: 25381eb4ae67
Author:    mcimadamore
Date:      2016-02-29 15:26 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/25381eb4ae67

Misc M3 fixes:
* added support for 'Where' attributes
* enhanced support for IFACMP_EQ/NE
* added better debugging when -XDvalhalla.dumpProxyClasses is enabled
* rectified logic for handling with qualified names and inner classes
* use '_' for reference parameterization everywhere instead of nulls or empty strings

! src/java.base/share/classes/java/lang/invoke/DispatchContext.java
! src/java.base/share/classes/java/net/URLClassLoader.java
! src/java.base/share/classes/valhalla/classdyn/ClassDynHelper.java
! src/java.base/share/classes/valhalla/model3/Model3Converter.java

Changeset: 62d1a69f2587
Author:    mcimadamore
Date:      2016-02-29 15:27 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/62d1a69f2587

merge

! src/java.base/share/classes/valhalla/model3/Model3Converter.java


From maurizio.cimadamore at oracle.com  Mon Feb 29 15:32:34 2016
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 29 Feb 2016 15:32:34 +0000
Subject: hg: valhalla/valhalla/hotspot: Fix: tweak bootstrap loader hack to
	handle M3 mangled names
Message-ID: <201602291532.u1TFWYBD013182@aojmv0008.oracle.com>

Changeset: 569fd7f71a32
Author:    mcimadamore
Date:      2016-02-29 15:32 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/569fd7f71a32

Fix: tweak bootstrap loader hack to handle M3 mangled names

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