From martijnverburg at gmail.com  Mon Nov  2 11:16:16 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 2 Nov 2015 11:16:16 +0000
Subject: Monthly notice for new signups to Project Valhalla - How to Contribute
Message-ID: <CAP7YuAQ7rkUmp74KGJRq4MbYAthMPi4UfYAHk2TUUUXXmJOvHQ@mail.gmail.com>

Hi all,

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 maurizio.cimadamore at oracle.com  Tue Nov  3 21:32:02 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 3 Nov 2015 21:32:02 +0000
Subject: Result: New Committer: Frederic Parain
Message-ID: <563927D2.2090005@oracle.com>

|Voting for ||Frederic Parain [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According 
to the Bylaws definition of Lazy Consensus, this is sufficient to 
approve the nomination. Maurizio [1] 
http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-February/001003.html|


From maurizio.cimadamore at oracle.com  Thu Nov  5 17:50:11 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 05 Nov 2015 17:50:11 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: apply descriptor
	adaptation when emitting generic specializable call sites
Message-ID: <201511051750.tA5HoBHm011027@aojmv0008.oracle.com>

Changeset: b47178ceea53
Author:    mcimadamore
Date:      2015-11-05 17:49 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b47178ceea53

Enhancement: apply descriptor adaptation when emitting generic specializable call sites

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.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
+ test/tools/javac/valhalla/typespec/items/tests/TestIndyErasure.java


From maurizio.cimadamore at oracle.com  Fri Nov  6 17:26:42 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 06 Nov 2015 17:26:42 +0000
Subject: hg: valhalla/valhalla/jdk: Fix: model 3 converter should load
	template class before attempting specialization
Message-ID: <201511061726.tA6HQhdM007892@aojmv0008.oracle.com>

Changeset: 1a61aaede3b8
Author:    mcimadamore
Date:      2015-11-06 17:26 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/1a61aaede3b8

Fix: model 3 converter should load template class before attempting specialization

! src/java.base/share/classes/java/net/URLClassLoader.java


From maurizio.cimadamore at oracle.com  Tue Nov 17 12:04:21 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 17 Nov 2015 12:04:21 +0000
Subject: hg: valhalla/valhalla/langtools: Misc value types fixes:
Message-ID: <201511171204.tAHC4LY5018056@aojmv0008.oracle.com>

Changeset: eb59ce39c7b0
Author:    mcimadamore
Date:      2015-11-17 12:04 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/eb59ce39c7b0

Misc value types fixes:
1. The parser does not accept local value type declarations of the form

__ByValue final class F { ... }

2. Enforcement that the fields of a value type should be final is not robust.

Contributed-by: srikanth.adayapalam at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/tools/javac/valhalla/values/CheckFinal.java
! test/tools/javac/valhalla/values/CheckFinal.out


From akarnokd at gmail.com  Wed Nov 18 13:27:13 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 14:27:13 +0100
Subject: Primitive Queue<any T> considerations
Message-ID: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>

Hello,

We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
in our library which exploits null as an indicator if the queue is full or
not. However, this won't work in case of a Queue<any T> because for
primitives, zero is a valid value.

I see two options:

  - use wider primitive and atomics-acessible types: byte -> int, char ->
int, short -> int, int -> long, float -> long, double -> 2 slots long and
long -> 2 slots of long
  - don't use fast-flow and go back to producer-consumer index comparison.

In either case, the internals and the usage have to be changed drastically,
i.e., switch to AtomicLongArray, how to indicate the queue is actually
empty when calling poll(), etc. Perhaps a new queue interface is necessary
where poll returns a boolean indicator and calls a Consumer if the data is
there.

The examples I saw regarding valhalla showed List<any T> where I'd guess
the internals of the ArrayList can be altered in a straightforward manner
but I don't see how this could happen if the algorithm itself has to change
based on what primitive T is.

What are the plans for supporting such kind of specializations?

-- 
Best regards,
David Karnok

From vitalyd at gmail.com  Wed Nov 18 13:35:27 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 08:35:27 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
Message-ID: <CAHjP37FjCm6UYf5DkPTBKKeosNxQ=ady5=Em1t19Gi6SqAx4LA@mail.gmail.com>

If Optional<T> (or some replacement/successor) can be made into a value
type, then it can be used instead.

On Wed, Nov 18, 2015 at 8:27 AM, D?vid Karnok <akarnokd at gmail.com> wrote:

> Hello,
>
> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
> in our library which exploits null as an indicator if the queue is full or
> not. However, this won't work in case of a Queue<any T> because for
> primitives, zero is a valid value.
>
> I see two options:
>
>   - use wider primitive and atomics-acessible types: byte -> int, char ->
> int, short -> int, int -> long, float -> long, double -> 2 slots long and
> long -> 2 slots of long
>   - don't use fast-flow and go back to producer-consumer index comparison.
>
> In either case, the internals and the usage have to be changed drastically,
> i.e., switch to AtomicLongArray, how to indicate the queue is actually
> empty when calling poll(), etc. Perhaps a new queue interface is necessary
> where poll returns a boolean indicator and calls a Consumer if the data is
> there.
>
> The examples I saw regarding valhalla showed List<any T> where I'd guess
> the internals of the ArrayList can be altered in a straightforward manner
> but I don't see how this could happen if the algorithm itself has to change
> based on what primitive T is.
>
> What are the plans for supporting such kind of specializations?
>
> --
> Best regards,
> David Karnok
>

From richard.warburton at gmail.com  Wed Nov 18 14:24:58 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Wed, 18 Nov 2015 06:24:58 -0800
Subject: Primitive Queue<any T> considerations
Message-ID: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>

Hi,

We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
> in our library which exploits null as an indicator if the queue is full or
> not. However, this won't work in case of a Queue<any T> because for
> primitives, zero is a valid value.
>
> I see two options:
>
>   - use wider primitive and atomics-acessible types: byte -> int, char ->
> int, short -> int, int -> long, float -> long, double -> 2 slots long and
> long -> 2 slots of long
>   - don't use fast-flow and go back to producer-consumer index comparison.
>
> In either case, the internals and the usage have to be changed drastically,
> i.e., switch to AtomicLongArray, how to indicate the queue is actually
> empty when calling poll(), etc. Perhaps a new queue interface is necessary
> where poll returns a boolean indicator and calls a Consumer if the data is
> there.
>
> The examples I saw regarding valhalla showed List<any T> where I'd guess
> the internals of the ArrayList can be altered in a straightforward manner
> but I don't see how this could happen if the algorithm itself has to change
> based on what primitive T is.
>
> What are the plans for supporting such kind of specializations?


As Vitaly says you can have a value type that represents presence/absence
in your backing array.

Another option is having a "missing" value. This is the approach that I use
when writing/using primitive collections. There always seems to be a number
value that you can using to represent a missing element whenever I've used
primitive specialized collections. That missing value can be used where
null is used for reference types.

.NET has a "default(T)" construct where default some value is constructed
for a type, eg 0 for primitives, null for references which can used as a
missing value or as a way to initialise backing arrays.

regards,

  Richard Warburton

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

From akarnokd at gmail.com  Wed Nov 18 14:59:45 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 15:59:45 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
Message-ID: <CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>

I'm not sure about the default null-indicator because every time a queue is
needed in our library, that can serve a source with unique choice of a
default-null value. It is unlikely the users of the library want or can
specify that all the time.

Of course, I can define a value type Cell<any T> where a mark word is
packed with the actual value. However, I'm not sure if it will be possible
to do lazySet on either the value or the mark word because volatile write
adds quite an overhead to an Spsc queue. The second problem is alignment in
Cell because Java doesn't have smaller than int size atomics (unlike C#),
i.e., Cell<short> should be aligned in a way the mark word is properly
accessible on all platforms.

Even if the poll() problem is solved by a new Queue interface (AnyQueue),
this common implementation I believe is still puts to much burden on a
reference-typed instance.

My question is, will there be some infrastructure (at runtime?) that let's
a library customize what

AnyQueue<T> q = new SpscArrayAnyQueue<>();

q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
turns out to be int or SpscArrayRefQueue<T> for ref types?



2015-11-18 15:24 GMT+01:00 Richard Warburton <richard.warburton at gmail.com>:

> Hi,
>
> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
> > in our library which exploits null as an indicator if the queue is full
> or
> > not. However, this won't work in case of a Queue<any T> because for
> > primitives, zero is a valid value.
> >
> > I see two options:
> >
> >   - use wider primitive and atomics-acessible types: byte -> int, char ->
> > int, short -> int, int -> long, float -> long, double -> 2 slots long and
> > long -> 2 slots of long
> >   - don't use fast-flow and go back to producer-consumer index
> comparison.
> >
> > In either case, the internals and the usage have to be changed
> drastically,
> > i.e., switch to AtomicLongArray, how to indicate the queue is actually
> > empty when calling poll(), etc. Perhaps a new queue interface is
> necessary
> > where poll returns a boolean indicator and calls a Consumer if the data
> is
> > there.
> >
> > The examples I saw regarding valhalla showed List<any T> where I'd guess
> > the internals of the ArrayList can be altered in a straightforward manner
> > but I don't see how this could happen if the algorithm itself has to
> change
> > based on what primitive T is.
> >
> > What are the plans for supporting such kind of specializations?
>
>
> As Vitaly says you can have a value type that represents presence/absence
> in your backing array.
>
> Another option is having a "missing" value. This is the approach that I use
> when writing/using primitive collections. There always seems to be a number
> value that you can using to represent a missing element whenever I've used
> primitive specialized collections. That missing value can be used where
> null is used for reference types.
>
> .NET has a "default(T)" construct where default some value is constructed
> for a type, eg 0 for primitives, null for references which can used as a
> missing value or as a way to initialise backing arrays.
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>



-- 
Best regards,
David Karnok

From vitalyd at gmail.com  Wed Nov 18 15:28:13 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 10:28:13 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
Message-ID: <CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>

>
>  However, I'm not sure if it will be possible
> to do lazySet on either the value or the mark word


why not? because value types must have final fields?

q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
> turns out to be int or SpscArrayRefQueue<T> for ref types?


how would your SpscArrayPrimitiveQueue<int> handle null values?

On Wed, Nov 18, 2015 at 9:59 AM, D?vid Karnok <akarnokd at gmail.com> wrote:

> I'm not sure about the default null-indicator because every time a queue is
> needed in our library, that can serve a source with unique choice of a
> default-null value. It is unlikely the users of the library want or can
> specify that all the time.
>
> Of course, I can define a value type Cell<any T> where a mark word is
> packed with the actual value. However, I'm not sure if it will be possible
> to do lazySet on either the value or the mark word because volatile write
> adds quite an overhead to an Spsc queue. The second problem is alignment in
> Cell because Java doesn't have smaller than int size atomics (unlike C#),
> i.e., Cell<short> should be aligned in a way the mark word is properly
> accessible on all platforms.
>
> Even if the poll() problem is solved by a new Queue interface (AnyQueue),
> this common implementation I believe is still puts to much burden on a
> reference-typed instance.
>
> My question is, will there be some infrastructure (at runtime?) that let's
> a library customize what
>
> AnyQueue<T> q = new SpscArrayAnyQueue<>();
>
> q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
> turns out to be int or SpscArrayRefQueue<T> for ref types?
>
>
>
> 2015-11-18 15:24 GMT+01:00 Richard Warburton <richard.warburton at gmail.com
> >:
>
> > Hi,
> >
> > We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite
> often
> > > in our library which exploits null as an indicator if the queue is full
> > or
> > > not. However, this won't work in case of a Queue<any T> because for
> > > primitives, zero is a valid value.
> > >
> > > I see two options:
> > >
> > >   - use wider primitive and atomics-acessible types: byte -> int, char
> ->
> > > int, short -> int, int -> long, float -> long, double -> 2 slots long
> and
> > > long -> 2 slots of long
> > >   - don't use fast-flow and go back to producer-consumer index
> > comparison.
> > >
> > > In either case, the internals and the usage have to be changed
> > drastically,
> > > i.e., switch to AtomicLongArray, how to indicate the queue is actually
> > > empty when calling poll(), etc. Perhaps a new queue interface is
> > necessary
> > > where poll returns a boolean indicator and calls a Consumer if the data
> > is
> > > there.
> > >
> > > The examples I saw regarding valhalla showed List<any T> where I'd
> guess
> > > the internals of the ArrayList can be altered in a straightforward
> manner
> > > but I don't see how this could happen if the algorithm itself has to
> > change
> > > based on what primitive T is.
> > >
> > > What are the plans for supporting such kind of specializations?
> >
> >
> > As Vitaly says you can have a value type that represents presence/absence
> > in your backing array.
> >
> > Another option is having a "missing" value. This is the approach that I
> use
> > when writing/using primitive collections. There always seems to be a
> number
> > value that you can using to represent a missing element whenever I've
> used
> > primitive specialized collections. That missing value can be used where
> > null is used for reference types.
> >
> > .NET has a "default(T)" construct where default some value is constructed
> > for a type, eg 0 for primitives, null for references which can used as a
> > missing value or as a way to initialise backing arrays.
> >
> > regards,
> >
> >   Richard Warburton
> >
> >   http://insightfullogic.com
> >   @RichardWarburto <http://twitter.com/richardwarburto>
> >
>
>
>
> --
> Best regards,
> David Karnok
>

From akarnokd at gmail.com  Wed Nov 18 16:22:39 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 17:22:39 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
Message-ID: <CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>

Let's assume I have a value type named cell:

valuetype Cell<any T> {
   public T value;
   public int mark;
}

and a power-of-2 array of cells:

Cell<any T>[] array;


having Cell with final fields is useless here because then I have a
constant array and not a queue.

This array forms the basis of my bounded, single-producer single-consumer
queue.

The implementation of offer(T) looks like this:

offset = producerIndex & (array.length - 1)
if (array[offset].mark != 0) {
    return false;
}
array[offset].value = v;
array[offset].mark = 1;
producerIndex++;

return true;

Due to the memory model requirements setting the mark field must be at
least ordered. In an AtomicReferenceArray, I'd use lazySet(offset) which
does the necessary barriers. Here, I either make mark volatile or have a
VarHandle point to it. I'm not sure if I will be able to do this within the
same JDK version at the moment.

Since poll() can no longer return null to indicate emptiness, I need a new
API method with the following definition to make it type-agnostic:

boolean poll(Consumer<? super T> consumer);

which calls the consumer with the available value and returns true or
returns false if the queue is empty.

SpscArrayPrimitiveQueue shouldn't encounter null because it gets only
instantiated when the SpscArrayAnyQueue instantiation is replaced by it.
This happens when the programmer explicitly declares the type parameter to
be a primitive. From then on, he/she can't use nulls with Queue<int>
because the compiler forbids it.

Somehow I doubt it will be possible to dispatch on the kind of T at runtime
from within Java:

<any T> AnyQueue<T> createQueue() {
   if (T instanceof class) {
      return (AnyQueue<T>)new SpscArrayRefQueue<(class)T>();
   } else
   if (T instanceof valuetype) {
      return (AnyQueue<T>)new SpscArrayPrimitiveQueue<(valuetype)T>();
   }
   throw new IllegalArgumentException();
}


2015-11-18 16:28 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:

>  However, I'm not sure if it will be possible
>> to do lazySet on either the value or the mark word
>
>
> why not? because value types must have final fields?
>
> q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
>> turns out to be int or SpscArrayRefQueue<T> for ref types?
>
>
> how would your SpscArrayPrimitiveQueue<int> handle null values?
>
> On Wed, Nov 18, 2015 at 9:59 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>
>> I'm not sure about the default null-indicator because every time a queue
>> is
>> needed in our library, that can serve a source with unique choice of a
>> default-null value. It is unlikely the users of the library want or can
>> specify that all the time.
>>
>> Of course, I can define a value type Cell<any T> where a mark word is
>> packed with the actual value. However, I'm not sure if it will be possible
>> to do lazySet on either the value or the mark word because volatile write
>> adds quite an overhead to an Spsc queue. The second problem is alignment
>> in
>> Cell because Java doesn't have smaller than int size atomics (unlike C#),
>> i.e., Cell<short> should be aligned in a way the mark word is properly
>> accessible on all platforms.
>>
>> Even if the poll() problem is solved by a new Queue interface (AnyQueue),
>> this common implementation I believe is still puts to much burden on a
>> reference-typed instance.
>>
>> My question is, will there be some infrastructure (at runtime?) that let's
>> a library customize what
>>
>> AnyQueue<T> q = new SpscArrayAnyQueue<>();
>>
>> q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
>> turns out to be int or SpscArrayRefQueue<T> for ref types?
>>
>>
>>
>> 2015-11-18 15:24 GMT+01:00 Richard Warburton <richard.warburton at gmail.com
>> >:
>>
>> > Hi,
>> >
>> > We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite
>> often
>> > > in our library which exploits null as an indicator if the queue is
>> full
>> > or
>> > > not. However, this won't work in case of a Queue<any T> because for
>> > > primitives, zero is a valid value.
>> > >
>> > > I see two options:
>> > >
>> > >   - use wider primitive and atomics-acessible types: byte -> int,
>> char ->
>> > > int, short -> int, int -> long, float -> long, double -> 2 slots long
>> and
>> > > long -> 2 slots of long
>> > >   - don't use fast-flow and go back to producer-consumer index
>> > comparison.
>> > >
>> > > In either case, the internals and the usage have to be changed
>> > drastically,
>> > > i.e., switch to AtomicLongArray, how to indicate the queue is actually
>> > > empty when calling poll(), etc. Perhaps a new queue interface is
>> > necessary
>> > > where poll returns a boolean indicator and calls a Consumer if the
>> data
>> > is
>> > > there.
>> > >
>> > > The examples I saw regarding valhalla showed List<any T> where I'd
>> guess
>> > > the internals of the ArrayList can be altered in a straightforward
>> manner
>> > > but I don't see how this could happen if the algorithm itself has to
>> > change
>> > > based on what primitive T is.
>> > >
>> > > What are the plans for supporting such kind of specializations?
>> >
>> >
>> > As Vitaly says you can have a value type that represents
>> presence/absence
>> > in your backing array.
>> >
>> > Another option is having a "missing" value. This is the approach that I
>> use
>> > when writing/using primitive collections. There always seems to be a
>> number
>> > value that you can using to represent a missing element whenever I've
>> used
>> > primitive specialized collections. That missing value can be used where
>> > null is used for reference types.
>> >
>> > .NET has a "default(T)" construct where default some value is
>> constructed
>> > for a type, eg 0 for primitives, null for references which can used as a
>> > missing value or as a way to initialise backing arrays.
>> >
>> > regards,
>> >
>> >   Richard Warburton
>> >
>> >   http://insightfullogic.com
>> >   @RichardWarburto <http://twitter.com/richardwarburto>
>> >
>>
>>
>>
>> --
>> Best regards,
>> David Karnok
>>
>
>


-- 
Best regards,
David Karnok

From brian.goetz at oracle.com  Wed Nov 18 16:26:03 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 11:26:03 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
Message-ID: <564CA69B.10700@oracle.com>

Having null as a universal sentinel is a darn convenient thing. Having 
that taken away is going to make life harder for some data structures.  
You've already identified a few ways to do that; pick a different 
algorithm, use a side-table to indicate special conditions like empty, 
or widen the data to include enough space to stuff a boolean.  (Optional 
has this same issue; the footprint of Optional can be a single ref but 
needs an extra bit for primitives like int which use all their bit 
patterns.)

Some value types have unused bit patterns which could be pressed into 
service as sentinels, but that doesn't help us with int, long, xy-point, 
complex, tuple of ints, etc -- these all use all the bit patterns to 
encode valid values.

As Richard points out, .NET has a default(T) -- which gives you the 
all-zero bit pattern for a given type (the value to which array elements 
and fields are initialized) -- and we will have the same (currently we 
spell this T.default.)  For some situations, this might be enough of a 
sentinel and requires no extra hoop jumping (though obviously zero is a 
useful integer and so it might not be suitable.)

Our current thoughts are to support some sort of 
hand-written-specialization for specific instantiations of a 
parameterized type, possibly at both method and whole-class 
granularities.  For example, one can write an ArrayList<any T> class, 
but one might (or might not, there's room for disagreement) want 
ArrayList<boolean> to use a bit vector rather than a boolean[].  
Similarly, the literature is full of specialized algorithms for hash 
maps from int to int.

Applying this to Optional, which is similar to your situation, there 
could be a generic implementation (which used a side boolean to indicate 
presence) and a specialized implementation for Optional<ref T>, which 
omits the boolean and uses null as the sentinel.

tl;dr: we're aware of this issue and have integrated it into the 
requirements set :)

On 11/18/2015 8:27 AM, D?vid Karnok wrote:
> Hello,
>
> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
> in our library which exploits null as an indicator if the queue is full or
> not. However, this won't work in case of a Queue<any T> because for
> primitives, zero is a valid value.
>
> I see two options:
>
>    - use wider primitive and atomics-acessible types: byte -> int, char ->
> int, short -> int, int -> long, float -> long, double -> 2 slots long and
> long -> 2 slots of long
>    - don't use fast-flow and go back to producer-consumer index comparison.
>
> In either case, the internals and the usage have to be changed drastically,
> i.e., switch to AtomicLongArray, how to indicate the queue is actually
> empty when calling poll(), etc. Perhaps a new queue interface is necessary
> where poll returns a boolean indicator and calls a Consumer if the data is
> there.
>
> The examples I saw regarding valhalla showed List<any T> where I'd guess
> the internals of the ArrayList can be altered in a straightforward manner
> but I don't see how this could happen if the algorithm itself has to change
> based on what primitive T is.
>
> What are the plans for supporting such kind of specializations?
>


From vitalyd at gmail.com  Wed Nov 18 16:34:59 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 11:34:59 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
Message-ID: <CAHjP37GpcwCoifLubj0z_dJHfcz-Bw4mGvn1xkz+H5mLAxAyyA@mail.gmail.com>

>
> having Cell with final fields is useless here because then I have a
> constant array and not a queue.


That's the current proposal (i.e. value types can only have final fields).
Can't say I'm too happy about that, but it is what it is.

The implementation of offer(T) looks like this:
> offset = producerIndex & (array.length - 1)
> if (array[offset].mark != 0) {
>     return false;
> }
> array[offset].value = v;
> array[offset].mark = 1;
> producerIndex++;
> return true;


Given the above, this would likely need to be:

array[offset] = new Cell<>(v,1);

Due to the memory model requirements setting the mark field must be at
> least ordered. In an AtomicReferenceArray, I'd use lazySet(offset) which
> does the necessary barriers. Here, I either make mark volatile or have a
> VarHandle point to it. I'm not sure if I will be able to do this within the
> same JDK version at the moment.


Well, in this particular case you can make producerIndex++ have a
store-store fence, but I agree with the general premise.  Perhaps
VarHandle/Arrays 2.0 will provide something here, or barring that, a manual
Unsafe/Fence storeFence() type of thing would suffice.

On Wed, Nov 18, 2015 at 11:22 AM, D?vid Karnok <akarnokd at gmail.com> wrote:

> Let's assume I have a value type named cell:
>
> valuetype Cell<any T> {
>    public T value;
>    public int mark;
> }
>
> and a power-of-2 array of cells:
>
> Cell<any T>[] array;
>
>
> having Cell with final fields is useless here because then I have a
> constant array and not a queue.
>
> This array forms the basis of my bounded, single-producer single-consumer
> queue.
>
> The implementation of offer(T) looks like this:
>
> offset = producerIndex & (array.length - 1)
> if (array[offset].mark != 0) {
>     return false;
> }
> array[offset].value = v;
> array[offset].mark = 1;
> producerIndex++;
>
> return true;
>
> Due to the memory model requirements setting the mark field must be at
> least ordered. In an AtomicReferenceArray, I'd use lazySet(offset) which
> does the necessary barriers. Here, I either make mark volatile or have a
> VarHandle point to it. I'm not sure if I will be able to do this within the
> same JDK version at the moment.
>
> Since poll() can no longer return null to indicate emptiness, I need a new
> API method with the following definition to make it type-agnostic:
>
> boolean poll(Consumer<? super T> consumer);
>
> which calls the consumer with the available value and returns true or
> returns false if the queue is empty.
>
> SpscArrayPrimitiveQueue shouldn't encounter null because it gets only
> instantiated when the SpscArrayAnyQueue instantiation is replaced by it.
> This happens when the programmer explicitly declares the type parameter to
> be a primitive. From then on, he/she can't use nulls with Queue<int>
> because the compiler forbids it.
>
> Somehow I doubt it will be possible to dispatch on the kind of T at
> runtime from within Java:
>
> <any T> AnyQueue<T> createQueue() {
>    if (T instanceof class) {
>       return (AnyQueue<T>)new SpscArrayRefQueue<(class)T>();
>    } else
>    if (T instanceof valuetype) {
>       return (AnyQueue<T>)new SpscArrayPrimitiveQueue<(valuetype)T>();
>    }
>    throw new IllegalArgumentException();
> }
>
>
> 2015-11-18 16:28 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:
>
>>  However, I'm not sure if it will be possible
>>> to do lazySet on either the value or the mark word
>>
>>
>> why not? because value types must have final fields?
>>
>> q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
>>> turns out to be int or SpscArrayRefQueue<T> for ref types?
>>
>>
>> how would your SpscArrayPrimitiveQueue<int> handle null values?
>>
>> On Wed, Nov 18, 2015 at 9:59 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>>
>>> I'm not sure about the default null-indicator because every time a queue
>>> is
>>> needed in our library, that can serve a source with unique choice of a
>>> default-null value. It is unlikely the users of the library want or can
>>> specify that all the time.
>>>
>>> Of course, I can define a value type Cell<any T> where a mark word is
>>> packed with the actual value. However, I'm not sure if it will be
>>> possible
>>> to do lazySet on either the value or the mark word because volatile write
>>> adds quite an overhead to an Spsc queue. The second problem is alignment
>>> in
>>> Cell because Java doesn't have smaller than int size atomics (unlike C#),
>>> i.e., Cell<short> should be aligned in a way the mark word is properly
>>> accessible on all platforms.
>>>
>>> Even if the poll() problem is solved by a new Queue interface (AnyQueue),
>>> this common implementation I believe is still puts to much burden on a
>>> reference-typed instance.
>>>
>>> My question is, will there be some infrastructure (at runtime?) that
>>> let's
>>> a library customize what
>>>
>>> AnyQueue<T> q = new SpscArrayAnyQueue<>();
>>>
>>> q can have an SpscArrayPrimitiveQueue<int> implementation returned if T
>>> turns out to be int or SpscArrayRefQueue<T> for ref types?
>>>
>>>
>>>
>>> 2015-11-18 15:24 GMT+01:00 Richard Warburton <
>>> richard.warburton at gmail.com>:
>>>
>>> > Hi,
>>> >
>>> > We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite
>>> often
>>> > > in our library which exploits null as an indicator if the queue is
>>> full
>>> > or
>>> > > not. However, this won't work in case of a Queue<any T> because for
>>> > > primitives, zero is a valid value.
>>> > >
>>> > > I see two options:
>>> > >
>>> > >   - use wider primitive and atomics-acessible types: byte -> int,
>>> char ->
>>> > > int, short -> int, int -> long, float -> long, double -> 2 slots
>>> long and
>>> > > long -> 2 slots of long
>>> > >   - don't use fast-flow and go back to producer-consumer index
>>> > comparison.
>>> > >
>>> > > In either case, the internals and the usage have to be changed
>>> > drastically,
>>> > > i.e., switch to AtomicLongArray, how to indicate the queue is
>>> actually
>>> > > empty when calling poll(), etc. Perhaps a new queue interface is
>>> > necessary
>>> > > where poll returns a boolean indicator and calls a Consumer if the
>>> data
>>> > is
>>> > > there.
>>> > >
>>> > > The examples I saw regarding valhalla showed List<any T> where I'd
>>> guess
>>> > > the internals of the ArrayList can be altered in a straightforward
>>> manner
>>> > > but I don't see how this could happen if the algorithm itself has to
>>> > change
>>> > > based on what primitive T is.
>>> > >
>>> > > What are the plans for supporting such kind of specializations?
>>> >
>>> >
>>> > As Vitaly says you can have a value type that represents
>>> presence/absence
>>> > in your backing array.
>>> >
>>> > Another option is having a "missing" value. This is the approach that
>>> I use
>>> > when writing/using primitive collections. There always seems to be a
>>> number
>>> > value that you can using to represent a missing element whenever I've
>>> used
>>> > primitive specialized collections. That missing value can be used where
>>> > null is used for reference types.
>>> >
>>> > .NET has a "default(T)" construct where default some value is
>>> constructed
>>> > for a type, eg 0 for primitives, null for references which can used as
>>> a
>>> > missing value or as a way to initialise backing arrays.
>>> >
>>> > regards,
>>> >
>>> >   Richard Warburton
>>> >
>>> >   http://insightfullogic.com
>>> >   @RichardWarburto <http://twitter.com/richardwarburto>
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> David Karnok
>>>
>>
>>
>
>
> --
> Best regards,
> David Karnok
>

From vitalyd at gmail.com  Wed Nov 18 16:43:33 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 11:43:33 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CA69B.10700@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
Message-ID: <CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>

>
> Our current thoughts are to support some sort of
> hand-written-specialization for specific instantiations of a parameterized
> type, possibly at both method and whole-class granularities.  For example,
> one can write an ArrayList<any T> class, but one might (or might not,
> there's room for disagreement) want ArrayList<boolean> to use a bit vector
> rather than a boolean[].  Similarly, the literature is full of specialized
> algorithms for hash maps from int to int.


Being able to specialize ArrayList<boolean> as bit vector, ala
std::vector<bool> in C++, would be great.  The more general feature of
being able to specialize internals is exciting to hear, assuming that comes
to fruition.

Applying this to Optional, which is similar to your situation, there could
> be a generic implementation (which used a side boolean to indicate
> presence) and a specialized implementation for Optional<ref T>, which omits
> the boolean and uses null as the sentinel.


Yes, this would be great as well; Rust does this type of thing, for example.

On Wed, Nov 18, 2015 at 11:26 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> Having null as a universal sentinel is a darn convenient thing. Having
> that taken away is going to make life harder for some data structures.
> You've already identified a few ways to do that; pick a different
> algorithm, use a side-table to indicate special conditions like empty, or
> widen the data to include enough space to stuff a boolean.  (Optional has
> this same issue; the footprint of Optional can be a single ref but needs an
> extra bit for primitives like int which use all their bit patterns.)
>
> Some value types have unused bit patterns which could be pressed into
> service as sentinels, but that doesn't help us with int, long, xy-point,
> complex, tuple of ints, etc -- these all use all the bit patterns to encode
> valid values.
>
> As Richard points out, .NET has a default(T) -- which gives you the
> all-zero bit pattern for a given type (the value to which array elements
> and fields are initialized) -- and we will have the same (currently we
> spell this T.default.)  For some situations, this might be enough of a
> sentinel and requires no extra hoop jumping (though obviously zero is a
> useful integer and so it might not be suitable.)
>
> Our current thoughts are to support some sort of
> hand-written-specialization for specific instantiations of a parameterized
> type, possibly at both method and whole-class granularities.  For example,
> one can write an ArrayList<any T> class, but one might (or might not,
> there's room for disagreement) want ArrayList<boolean> to use a bit vector
> rather than a boolean[].  Similarly, the literature is full of specialized
> algorithms for hash maps from int to int.
>
> Applying this to Optional, which is similar to your situation, there could
> be a generic implementation (which used a side boolean to indicate
> presence) and a specialized implementation for Optional<ref T>, which omits
> the boolean and uses null as the sentinel.
>
> tl;dr: we're aware of this issue and have integrated it into the
> requirements set :)
>
>
> On 11/18/2015 8:27 AM, D?vid Karnok wrote:
>
>> Hello,
>>
>> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite
>> often
>> in our library which exploits null as an indicator if the queue is full or
>> not. However, this won't work in case of a Queue<any T> because for
>> primitives, zero is a valid value.
>>
>> I see two options:
>>
>>    - use wider primitive and atomics-acessible types: byte -> int, char ->
>> int, short -> int, int -> long, float -> long, double -> 2 slots long and
>> long -> 2 slots of long
>>    - don't use fast-flow and go back to producer-consumer index
>> comparison.
>>
>> In either case, the internals and the usage have to be changed
>> drastically,
>> i.e., switch to AtomicLongArray, how to indicate the queue is actually
>> empty when calling poll(), etc. Perhaps a new queue interface is necessary
>> where poll returns a boolean indicator and calls a Consumer if the data is
>> there.
>>
>> The examples I saw regarding valhalla showed List<any T> where I'd guess
>> the internals of the ArrayList can be altered in a straightforward manner
>> but I don't see how this could happen if the algorithm itself has to
>> change
>> based on what primitive T is.
>>
>> What are the plans for supporting such kind of specializations?
>>
>>
>

From akarnokd at gmail.com  Wed Nov 18 17:00:39 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 18:00:39 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
Message-ID: <CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>

Thanks Brian & Vitaly.

Just a few final remarks and I'll consider my question answered.

If value types are to be final, that's fine as long as assignment works,
however, the purpose of the fast-flow algorithm to use the cell itself so
there is only one cache miss. Even if producerIndex has release semantics,
I have to read producerIndex in poll() for acquire semantics before reading
the cell which now may yield two cache misses.

If value types are final, that means the array-store and array-load have to
be atomic in some way for fast-flow to work, i.e., mark has to be written
last and read first in the structured array.

(In addition, not sure where or how Gil Tene's ObjectLayout would fit in
because that proposal allows field mutation but forbids whole cell
assignment.)

2015-11-18 17:43 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:

> Our current thoughts are to support some sort of
>> hand-written-specialization for specific instantiations of a parameterized
>> type, possibly at both method and whole-class granularities.  For example,
>> one can write an ArrayList<any T> class, but one might (or might not,
>> there's room for disagreement) want ArrayList<boolean> to use a bit vector
>> rather than a boolean[].  Similarly, the literature is full of specialized
>> algorithms for hash maps from int to int.
>
>
> Being able to specialize ArrayList<boolean> as bit vector, ala
> std::vector<bool> in C++, would be great.  The more general feature of
> being able to specialize internals is exciting to hear, assuming that comes
> to fruition.
>
> Applying this to Optional, which is similar to your situation, there could
>> be a generic implementation (which used a side boolean to indicate
>> presence) and a specialized implementation for Optional<ref T>, which omits
>> the boolean and uses null as the sentinel.
>
>
> Yes, this would be great as well; Rust does this type of thing, for
> example.
>
> On Wed, Nov 18, 2015 at 11:26 AM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Having null as a universal sentinel is a darn convenient thing. Having
>> that taken away is going to make life harder for some data structures.
>> You've already identified a few ways to do that; pick a different
>> algorithm, use a side-table to indicate special conditions like empty, or
>> widen the data to include enough space to stuff a boolean.  (Optional has
>> this same issue; the footprint of Optional can be a single ref but needs an
>> extra bit for primitives like int which use all their bit patterns.)
>>
>> Some value types have unused bit patterns which could be pressed into
>> service as sentinels, but that doesn't help us with int, long, xy-point,
>> complex, tuple of ints, etc -- these all use all the bit patterns to encode
>> valid values.
>>
>> As Richard points out, .NET has a default(T) -- which gives you the
>> all-zero bit pattern for a given type (the value to which array elements
>> and fields are initialized) -- and we will have the same (currently we
>> spell this T.default.)  For some situations, this might be enough of a
>> sentinel and requires no extra hoop jumping (though obviously zero is a
>> useful integer and so it might not be suitable.)
>>
>> Our current thoughts are to support some sort of
>> hand-written-specialization for specific instantiations of a parameterized
>> type, possibly at both method and whole-class granularities.  For example,
>> one can write an ArrayList<any T> class, but one might (or might not,
>> there's room for disagreement) want ArrayList<boolean> to use a bit vector
>> rather than a boolean[].  Similarly, the literature is full of specialized
>> algorithms for hash maps from int to int.
>>
>> Applying this to Optional, which is similar to your situation, there
>> could be a generic implementation (which used a side boolean to indicate
>> presence) and a specialized implementation for Optional<ref T>, which omits
>> the boolean and uses null as the sentinel.
>>
>> tl;dr: we're aware of this issue and have integrated it into the
>> requirements set :)
>>
>>
>> On 11/18/2015 8:27 AM, D?vid Karnok wrote:
>>
>>> Hello,
>>>
>>> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite
>>> often
>>> in our library which exploits null as an indicator if the queue is full
>>> or
>>> not. However, this won't work in case of a Queue<any T> because for
>>> primitives, zero is a valid value.
>>>
>>> I see two options:
>>>
>>>    - use wider primitive and atomics-acessible types: byte -> int, char
>>> ->
>>> int, short -> int, int -> long, float -> long, double -> 2 slots long and
>>> long -> 2 slots of long
>>>    - don't use fast-flow and go back to producer-consumer index
>>> comparison.
>>>
>>> In either case, the internals and the usage have to be changed
>>> drastically,
>>> i.e., switch to AtomicLongArray, how to indicate the queue is actually
>>> empty when calling poll(), etc. Perhaps a new queue interface is
>>> necessary
>>> where poll returns a boolean indicator and calls a Consumer if the data
>>> is
>>> there.
>>>
>>> The examples I saw regarding valhalla showed List<any T> where I'd guess
>>> the internals of the ArrayList can be altered in a straightforward manner
>>> but I don't see how this could happen if the algorithm itself has to
>>> change
>>> based on what primitive T is.
>>>
>>> What are the plans for supporting such kind of specializations?
>>>
>>>
>>
>


-- 
Best regards,
David Karnok

From vitalyd at gmail.com  Wed Nov 18 17:56:20 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 12:56:20 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
Message-ID: <CAHjP37FU2v9L4yxL8D1KmKn4LFC04fgRPy-HgbdBPUchLdU67w@mail.gmail.com>

>
> If value types are to be final, that's fine as long as assignment works,
> however, the purpose of the fast-flow algorithm to use the cell itself so
> there is only one cache miss. Even if producerIndex has release semantics,
> I have to read producerIndex in poll() for acquire semantics before reading
> the cell which now may yield two cache misses.


Yes, agreed.

If value types are final, that means the array-store and array-load have to
> be atomic in some way for fast-flow to work, i.e., mark has to be written
> last and read first in the structured array


Yes, this is a tough one I think (i.e. cannot write arbitrary sized value
types atomically).  In .NET, this is simply not allowed, e.g. you cannot do
atomic operations on a DateTime, even though it happens to be 8 bytes.  In
those cases, people fallback to using the underlying primitive (long, in
this case) and convert to the value type on the fly.  This isn't too bad
since it becomes an internal implementation detail only.  If you cannot
encode the required state into the widest atomic unit, then you're SOL
unfortunately.

(In addition, not sure where or how Gil Tene's ObjectLayout would fit in
> because that proposal allows field mutation but forbids whole cell
> assignment.)


Not sure either.  I know Volker Simonis from SAP was prototyping JIT
support for this, but no clue where this proposal is headed, if anywhere.

On Wed, Nov 18, 2015 at 12:00 PM, D?vid Karnok <akarnokd at gmail.com> wrote:

> Thanks Brian & Vitaly.
>
> Just a few final remarks and I'll consider my question answered.
>
> If value types are to be final, that's fine as long as assignment works,
> however, the purpose of the fast-flow algorithm to use the cell itself so
> there is only one cache miss. Even if producerIndex has release semantics,
> I have to read producerIndex in poll() for acquire semantics before reading
> the cell which now may yield two cache misses.
>
> If value types are final, that means the array-store and array-load have
> to be atomic in some way for fast-flow to work, i.e., mark has to be
> written last and read first in the structured array.
>
> (In addition, not sure where or how Gil Tene's ObjectLayout would fit in
> because that proposal allows field mutation but forbids whole cell
> assignment.)
>
> 2015-11-18 17:43 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:
>
>> Our current thoughts are to support some sort of
>>> hand-written-specialization for specific instantiations of a parameterized
>>> type, possibly at both method and whole-class granularities.  For example,
>>> one can write an ArrayList<any T> class, but one might (or might not,
>>> there's room for disagreement) want ArrayList<boolean> to use a bit vector
>>> rather than a boolean[].  Similarly, the literature is full of specialized
>>> algorithms for hash maps from int to int.
>>
>>
>> Being able to specialize ArrayList<boolean> as bit vector, ala
>> std::vector<bool> in C++, would be great.  The more general feature of
>> being able to specialize internals is exciting to hear, assuming that comes
>> to fruition.
>>
>> Applying this to Optional, which is similar to your situation, there
>>> could be a generic implementation (which used a side boolean to indicate
>>> presence) and a specialized implementation for Optional<ref T>, which omits
>>> the boolean and uses null as the sentinel.
>>
>>
>> Yes, this would be great as well; Rust does this type of thing, for
>> example.
>>
>> On Wed, Nov 18, 2015 at 11:26 AM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> Having null as a universal sentinel is a darn convenient thing. Having
>>> that taken away is going to make life harder for some data structures.
>>> You've already identified a few ways to do that; pick a different
>>> algorithm, use a side-table to indicate special conditions like empty, or
>>> widen the data to include enough space to stuff a boolean.  (Optional has
>>> this same issue; the footprint of Optional can be a single ref but needs an
>>> extra bit for primitives like int which use all their bit patterns.)
>>>
>>> Some value types have unused bit patterns which could be pressed into
>>> service as sentinels, but that doesn't help us with int, long, xy-point,
>>> complex, tuple of ints, etc -- these all use all the bit patterns to encode
>>> valid values.
>>>
>>> As Richard points out, .NET has a default(T) -- which gives you the
>>> all-zero bit pattern for a given type (the value to which array elements
>>> and fields are initialized) -- and we will have the same (currently we
>>> spell this T.default.)  For some situations, this might be enough of a
>>> sentinel and requires no extra hoop jumping (though obviously zero is a
>>> useful integer and so it might not be suitable.)
>>>
>>> Our current thoughts are to support some sort of
>>> hand-written-specialization for specific instantiations of a parameterized
>>> type, possibly at both method and whole-class granularities.  For example,
>>> one can write an ArrayList<any T> class, but one might (or might not,
>>> there's room for disagreement) want ArrayList<boolean> to use a bit vector
>>> rather than a boolean[].  Similarly, the literature is full of specialized
>>> algorithms for hash maps from int to int.
>>>
>>> Applying this to Optional, which is similar to your situation, there
>>> could be a generic implementation (which used a side boolean to indicate
>>> presence) and a specialized implementation for Optional<ref T>, which omits
>>> the boolean and uses null as the sentinel.
>>>
>>> tl;dr: we're aware of this issue and have integrated it into the
>>> requirements set :)
>>>
>>>
>>> On 11/18/2015 8:27 AM, D?vid Karnok wrote:
>>>
>>>> Hello,
>>>>
>>>> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite
>>>> often
>>>> in our library which exploits null as an indicator if the queue is full
>>>> or
>>>> not. However, this won't work in case of a Queue<any T> because for
>>>> primitives, zero is a valid value.
>>>>
>>>> I see two options:
>>>>
>>>>    - use wider primitive and atomics-acessible types: byte -> int, char
>>>> ->
>>>> int, short -> int, int -> long, float -> long, double -> 2 slots long
>>>> and
>>>> long -> 2 slots of long
>>>>    - don't use fast-flow and go back to producer-consumer index
>>>> comparison.
>>>>
>>>> In either case, the internals and the usage have to be changed
>>>> drastically,
>>>> i.e., switch to AtomicLongArray, how to indicate the queue is actually
>>>> empty when calling poll(), etc. Perhaps a new queue interface is
>>>> necessary
>>>> where poll returns a boolean indicator and calls a Consumer if the data
>>>> is
>>>> there.
>>>>
>>>> The examples I saw regarding valhalla showed List<any T> where I'd guess
>>>> the internals of the ArrayList can be altered in a straightforward
>>>> manner
>>>> but I don't see how this could happen if the algorithm itself has to
>>>> change
>>>> based on what primitive T is.
>>>>
>>>> What are the plans for supporting such kind of specializations?
>>>>
>>>>
>>>
>>
>
>
> --
> Best regards,
> David Karnok
>

From duncan.macgregor at ge.com  Wed Nov 18 18:53:11 2015
From: duncan.macgregor at ge.com (MacGregor, Duncan (GE Energy Management))
Date: Wed, 18 Nov 2015 18:53:11 +0000
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
Message-ID: <D2727832.11176B%duncan.macgregor@ge.com>



On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
<valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com>
wrote:

>Let's assume I have a value type named cell:
>
>valuetype Cell<any T> {
>   public T value;
>   public int mark;
>}
>
>and a power-of-2 array of cells:
>
>Cell<any T>[] array;
>
>
>having Cell with final fields is useless here because then I have a
>constant array and not a queue.

Maybe I?m not following you here but the fact fields on a Cell are final
does not stop you from replacing one Cell in array with a new Cell, just
as you can replace individual ints in an array of ints.

So you offset method would be more like

offset = producerIndex & (array.length - 1)
if (array[offset].mark != 0) {
    return false;
}
array[offset] = Cell(value, 1);
producerIndex++;

return true;

And that operation on the array will be guaranteed to be atomic (though
probably needs a compare and swap in case another thread is trying to do
the same thing).

Duncan.


From vitalyd at gmail.com  Wed Nov 18 18:55:42 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 13:55:42 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <D2727832.11176B%duncan.macgregor@ge.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
Message-ID: <CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>

As discussed upthread, how would that operation be atomic for arbitrarily
sized value types?

On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy Management) <
duncan.macgregor at ge.com> wrote:

>
>
> On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
> <valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com>
> wrote:
>
> >Let's assume I have a value type named cell:
> >
> >valuetype Cell<any T> {
> >   public T value;
> >   public int mark;
> >}
> >
> >and a power-of-2 array of cells:
> >
> >Cell<any T>[] array;
> >
> >
> >having Cell with final fields is useless here because then I have a
> >constant array and not a queue.
>
> Maybe I?m not following you here but the fact fields on a Cell are final
> does not stop you from replacing one Cell in array with a new Cell, just
> as you can replace individual ints in an array of ints.
>
> So you offset method would be more like
>
> offset = producerIndex & (array.length - 1)
> if (array[offset].mark != 0) {
>     return false;
> }
> array[offset] = Cell(value, 1);
> producerIndex++;
>
> return true;
>
> And that operation on the array will be guaranteed to be atomic (though
> probably needs a compare and swap in case another thread is trying to do
> the same thing).
>
> Duncan.
>
>

From timo.kinnunen at gmail.com  Wed Nov 18 19:15:56 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 18 Nov 2015 20:15:56 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
Message-ID: <564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>

Hi, 

That?s a good question. How would arbitrary-sized values be assigned into an array without any other thread observing the value halfway between two states with its invariants not holding? 

As is mentioned in the JLS in 17.6: ?One consideration for implementations of the Java Virtual Machine is that every field and array element is considered distinct; updates to one field or element must not interact with reads or updates of any other field or element.? This probably has to be weakened in the same way as non-atomic reads/writes of long.





Sent from Mail for Windows 10



From: Vitaly Davidovich
Sent: Wednesday, November 18, 2015 19:56
To: MacGregor, Duncan (GE Energy Management)
Cc: valhalla-dev at openjdk.java.net
Subject: Re: Primitive Queue considerations


As discussed upthread, how would that operation be atomic for arbitrarily
sized value types?

On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy Management) <
duncan.macgregor at ge.com> wrote:

>
>
> On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
> <valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com>
> wrote:
>
> >Let's assume I have a value type named cell:
> >
> >valuetype Cell<any T> {
> >   public T value;
> >   public int mark;
> >}
> >
> >and a power-of-2 array of cells:
> >
> >Cell<any T>[] array;
> >
> >
> >having Cell with final fields is useless here because then I have a
> >constant array and not a queue.
>
> Maybe I?m not following you here but the fact fields on a Cell are final
> does not stop you from replacing one Cell in array with a new Cell, just
> as you can replace individual ints in an array of ints.
>
> So you offset method would be more like
>
> offset = producerIndex & (array.length - 1)
> if (array[offset].mark != 0) {
>     return false;
> }
> array[offset] = Cell(value, 1);
> producerIndex++;
>
> return true;
>
> And that operation on the array will be guaranteed to be atomic (though
> probably needs a compare and swap in case another thread is trying to do
> the same thing).
>
> Duncan.
>
>



From richard.warburton at gmail.com  Wed Nov 18 19:18:25 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Wed, 18 Nov 2015 11:18:25 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
Message-ID: <CAMaYbvJ0N7xJpH-PTr6Oe2aVsE+zqA4rqZVyTgLV94PrEG4HPQ@mail.gmail.com>

Hi,

I'm not sure about the default null-indicator because every time a queue is
> needed in our library, that can serve a source with unique choice of a
> default-null value. It is unlikely the users of the library want or can
> specify that all the time.
>

I appreciate that this is diverging directly form your language related
question, but it is pertinent to writing anyfied collections using
Valhalla. My experience using primitive specialised collections is that it
has always been possible to have a sentinel value, though obviously my
experience won't necessary reflect that of every single person in the Java
community. It isn't always appropriate for it to be 0, which is what I
think T.default is currently going to return for primitives and when I've
done primitive specialised collections before they allow you to specify the
missing value sentinel.

Have you got of an actual genuine use case where a sentinel value doesn't
work well, rather than a theoretical "hey, maybe you want to have a set
that contains every possible int?"

regards,

  Richard Warburton

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

From vitalyd at gmail.com  Wed Nov 18 19:30:36 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 14:30:36 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAMaYbvJ0N7xJpH-PTr6Oe2aVsE+zqA4rqZVyTgLV94PrEG4HPQ@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAMaYbvJ0N7xJpH-PTr6Oe2aVsE+zqA4rqZVyTgLV94PrEG4HPQ@mail.gmail.com>
Message-ID: <CAHjP37EoPRcSSPb23k1nPQrcWBV46p=CXxzSd8irqG6pku1PAg@mail.gmail.com>

Although I agree that sometimes a sentinel or even an entire range of
values is available to indicate absence, I don't think it's the right
answer to the question.  In particular, if you're writing a general purpose
collection, you cannot expect your users to remove one possible value from
their universe to signal absence.  The collections that do this today are
simply working around lack of nullable primitives.

On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
richard.warburton at gmail.com> wrote:

> Hi,
>
> I'm not sure about the default null-indicator because every time a queue is
> > needed in our library, that can serve a source with unique choice of a
> > default-null value. It is unlikely the users of the library want or can
> > specify that all the time.
> >
>
> I appreciate that this is diverging directly form your language related
> question, but it is pertinent to writing anyfied collections using
> Valhalla. My experience using primitive specialised collections is that it
> has always been possible to have a sentinel value, though obviously my
> experience won't necessary reflect that of every single person in the Java
> community. It isn't always appropriate for it to be 0, which is what I
> think T.default is currently going to return for primitives and when I've
> done primitive specialised collections before they allow you to specify the
> missing value sentinel.
>
> Have you got of an actual genuine use case where a sentinel value doesn't
> work well, rather than a theoretical "hey, maybe you want to have a set
> that contains every possible int?"
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>

From timo.kinnunen at gmail.com  Wed Nov 18 19:41:26 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 18 Nov 2015 20:41:26 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37EoPRcSSPb23k1nPQrcWBV46p=CXxzSd8irqG6pku1PAg@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAMaYbvJ0N7xJpH-PTr6Oe2aVsE+zqA4rqZVyTgLV94PrEG4HPQ@mail.gmail.com>
	<CAHjP37EoPRcSSPb23k1nPQrcWBV46p=CXxzSd8irqG6pku1PAg@mail.gmail.com>
Message-ID: <564cd479.93301c0a.109cf.2358@mx.google.com>

Even a Set of all ints has N= (8 + - Integer.MIN_VALUE) candidates for the sentinel value to choose from, it?s just not known which ones they are.

So choosing a new one at random has better than 1:1 odds of success.



Sent from Mail for Windows 10



From: Vitaly Davidovich
Sent: Wednesday, November 18, 2015 20:31
To: Richard Warburton
Cc: valhalla-dev at openjdk.java.net
Subject: Re: Primitive Queue considerations


Although I agree that sometimes a sentinel or even an entire range of
values is available to indicate absence, I don't think it's the right
answer to the question.  In particular, if you're writing a general purpose
collection, you cannot expect your users to remove one possible value from
their universe to signal absence.  The collections that do this today are
simply working around lack of nullable primitives.

On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
richard.warburton at gmail.com> wrote:

> Hi,
>
> I'm not sure about the default null-indicator because every time a queue is
> > needed in our library, that can serve a source with unique choice of a
> > default-null value. It is unlikely the users of the library want or can
> > specify that all the time.
> >
>
> I appreciate that this is diverging directly form your language related
> question, but it is pertinent to writing anyfied collections using
> Valhalla. My experience using primitive specialised collections is that it
> has always been possible to have a sentinel value, though obviously my
> experience won't necessary reflect that of every single person in the Java
> community. It isn't always appropriate for it to be 0, which is what I
> think T.default is currently going to return for primitives and when I've
> done primitive specialised collections before they allow you to specify the
> missing value sentinel.
>
> Have you got of an actual genuine use case where a sentinel value doesn't
> work well, rather than a theoretical "hey, maybe you want to have a set
> that contains every possible int?"
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>



From akarnokd at gmail.com  Wed Nov 18 19:48:01 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 20:48:01 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAMaYbvJ0N7xJpH-PTr6Oe2aVsE+zqA4rqZVyTgLV94PrEG4HPQ@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAMaYbvJ0N7xJpH-PTr6Oe2aVsE+zqA4rqZVyTgLV94PrEG4HPQ@mail.gmail.com>
Message-ID: <CAAWwtm994MAO3vSrvQ0EXwZN7=gosk7e2UNeg1MHfBoa2xkKOw@mail.gmail.com>

Here is an example of a reactive service composition which involves
Integers as of now:

Observable<Integer> retrofitItemCount(int id) { ... }

Observable.range(0, 10)
.flatMap(v -> retrofitItemCount(v))
.reduce(0, (a, b) -> a + b)
.observeOn(SwingScheduler.instance())
.subscribe(...)

This setup involves 12 queues that would require specifying default value:
- 1 queue that may hold the values from range 0..9 in flatMap
- 10 queues that may hold the number returned from the service call, again
in flatMap
- 1 queue that holds the sum until the Swing Event Dispatch loop can pick
it up in observeOn.

We are currently using null-sentinel objects which can be always
distinguished from regular values but this option goes away with value
types.

The problem with user specified default value is that it leaks into every
level of a library.

My original problem, on one hand can be solved with implementation that
uses some extra data fields to indicate a cell is empty or occupied; I have
prototype implementations of such primitive queues right now. The problem
is that how will I be able to use them as the specialized implementation
when Queue<any T> is resolved for int, long, struct, etc.


2015-11-18 20:18 GMT+01:00 Richard Warburton <richard.warburton at gmail.com>:

> Hi,
>
> I'm not sure about the default null-indicator because every time a queue
>> is needed in our library, that can serve a source with unique choice of a
>> default-null value. It is unlikely the users of the library want or can
>> specify that all the time.
>>
>
> I appreciate that this is diverging directly form your language related
> question, but it is pertinent to writing anyfied collections using
> Valhalla. My experience using primitive specialised collections is that it
> has always been possible to have a sentinel value, though obviously my
> experience won't necessary reflect that of every single person in the Java
> community. It isn't always appropriate for it to be 0, which is what I
> think T.default is currently going to return for primitives and when I've
> done primitive specialised collections before they allow you to specify the
> missing value sentinel.
>
> Have you got of an actual genuine use case where a sentinel value doesn't
> work well, rather than a theoretical "hey, maybe you want to have a set
> that contains every possible int?"
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>



-- 
Best regards,
David Karnok

From brian.goetz at oracle.com  Wed Nov 18 19:56:22 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 14:56:22 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
Message-ID: <564CD7E6.3050103@oracle.com>


> If value types are final, that means the array-store and array-load 
> have to be atomic in some way for fast-flow to work, i.e., mark has to 
> be written last and read first in the structured array.
>

That would be putting it too strongly.

Your concern is structure tearing.  If thread A writes a value to an 
array element (or a field) and thread B reads it, you are concerned that 
the reader see some consistent value that was put there by a single 
write in the past (even if stale.)

Obviously for "small enough" values, this isn't an issue, but small 
enough is pretty small (64 bits on today's hardware).   Also note that 
the JLS / JVMS have allowed tearing of longs and doubles since day one, 
unless they are declared volatile.

Note that the bad outcome -- tearing -- /only happens in the presence of 
a data race/.  So the question is, what should we do to protect the 
too-clever (and too-unclever) folks from their own mistakes?  The answer 
is certainly not to make all value reads and writes atomics -- this 
would be burdening all of the users who follow the rules with a 
crippling performance penalty (and it is really bad for 
larger-than-64-bit values) for the sake of the few who are living on the 
edge.

So the answer is not "reads and writes need to be atomic", but instead 
"there should be a way to ask for atomic reads/writes."  The current 
front-runner here builds on an existing story -- using volatile to make 
longs/double fields atomic.  We can easily extend this to values.

That leaves two cases uncovered:
  - What about arrays -- there is currently no means to declare an array 
with volatile (or final) elements.  This is being explored now.
  - What about classes that are intrinsically security-sensitive, and 
could not tolerate tearing in any case?  For this case, we are 
considering a declaration-site indication that a value is "unbreakable".

Summary:
  - Tearing is going to be a risk when accessing shared mutable state 
via a data race.
  - There will be use-site and likely also declaration-site tools to opt 
into atomicity, with a cost.



From vitalyd at gmail.com  Wed Nov 18 19:57:06 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 14:57:06 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
Message-ID: <CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>

FWIW, CLR explicitly states that value type assignments larger than machine
word size are not atomic.  Or rather, it guarantees that any value type of
size <= machine word will be atomic (modulo someone playing around with
struct layout manually).  As far as I know, there's never been much fuss
about this stipulation.

On Wed, Nov 18, 2015 at 2:15 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
wrote:

> Hi,
>
>
>
> That?s a good question. How would arbitrary-sized values be assigned into
> an array without any other thread observing the value halfway between two
> states with its invariants not holding?
>
>
>
> As is mentioned in the JLS in 17.6: ?One consideration for implementations
> of the Java Virtual Machine is that every field and array element is
> considered distinct; updates to one field or element must not interact with
> reads or updates of any other field or element.? This probably has to be
> weakened in the same way as non-atomic reads/writes of long.
>
>
>
>
>
>
>
>
>
>
>
> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
>
>
>
> *From: *Vitaly Davidovich
> *Sent: *Wednesday, November 18, 2015 19:56
> *To: *MacGregor, Duncan (GE Energy Management)
> *Cc: *valhalla-dev at openjdk.java.net
> *Subject: *Re: Primitive Queue considerations
>
>
>
>
>
> As discussed upthread, how would that operation be atomic for arbitrarily
>
> sized value types?
>
>
>
> On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy Management) <
>
> duncan.macgregor at ge.com> wrote:
>
>
>
> >
>
> >
>
> > On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
>
> > <valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com>
>
> > wrote:
>
> >
>
> > >Let's assume I have a value type named cell:
>
> > >
>
> > >valuetype Cell<any T> {
>
> > >   public T value;
>
> > >   public int mark;
>
> > >}
>
> > >
>
> > >and a power-of-2 array of cells:
>
> > >
>
> > >Cell<any T>[] array;
>
> > >
>
> > >
>
> > >having Cell with final fields is useless here because then I have a
>
> > >constant array and not a queue.
>
> >
>
> > Maybe I?m not following you here but the fact fields on a Cell are final
>
> > does not stop you from replacing one Cell in array with a new Cell, just
>
> > as you can replace individual ints in an array of ints.
>
> >
>
> > So you offset method would be more like
>
> >
>
> > offset = producerIndex & (array.length - 1)
>
> > if (array[offset].mark != 0) {
>
> >     return false;
>
> > }
>
> > array[offset] = Cell(value, 1);
>
> > producerIndex++;
>
> >
>
> > return true;
>
> >
>
> > And that operation on the array will be guaranteed to be atomic (though
>
> > probably needs a compare and swap in case another thread is trying to do
>
> > the same thing).
>
> >
>
> > Duncan.
>
> >
>
> >
>
>
>
>
>

From vitalyd at gmail.com  Wed Nov 18 20:01:15 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 15:01:15 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CD7E6.3050103@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
Message-ID: <CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>

This is good to hear Brian.

So the answer is not "reads and writes need to be atomic", but instead
> "there should be a way to ask for atomic reads/writes."  The current
> front-runner here builds on an existing story -- using volatile to make
> longs/double fields atomic.  We can easily extend this to values.


Just to spitball this a bit, if the value type is larger than max atomic
transfer unit on the machine, what's the thinking? I suppose you'd need
some locking, but where would it get a lock for this? Would a synthetic one
be generated automatically (javac or JVM)?

On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>
> If value types are final, that means the array-store and array-load have
> to be atomic in some way for fast-flow to work, i.e., mark has to be
> written last and read first in the structured array.
>
>
> That would be putting it too strongly.
>
> Your concern is structure tearing.  If thread A writes a value to an array
> element (or a field) and thread B reads it, you are concerned that the
> reader see some consistent value that was put there by a single write in
> the past (even if stale.)
>
> Obviously for "small enough" values, this isn't an issue, but small enough
> is pretty small (64 bits on today's hardware).   Also note that the JLS /
> JVMS have allowed tearing of longs and doubles since day one, unless they
> are declared volatile.
>
> Note that the bad outcome -- tearing -- *only happens in the presence of
> a data race*.  So the question is, what should we do to protect the
> too-clever (and too-unclever) folks from their own mistakes?  The answer is
> certainly not to make all value reads and writes atomics -- this would be
> burdening all of the users who follow the rules with a crippling
> performance penalty (and it is really bad for larger-than-64-bit values)
> for the sake of the few who are living on the edge.
>
> So the answer is not "reads and writes need to be atomic", but instead
> "there should be a way to ask for atomic reads/writes."  The current
> front-runner here builds on an existing story -- using volatile to make
> longs/double fields atomic.  We can easily extend this to values.
>
> That leaves two cases uncovered:
>  - What about arrays -- there is currently no means to declare an array
> with volatile (or final) elements.  This is being explored now.
>  - What about classes that are intrinsically security-sensitive, and could
> not tolerate tearing in any case?  For this case, we are considering a
> declaration-site indication that a value is "unbreakable".
>
> Summary:
>  - Tearing is going to be a risk when accessing shared mutable state via a
> data race.
>  - There will be use-site and likely also declaration-site tools to opt
> into atomicity, with a cost.
>
>
>

From brian.goetz at oracle.com  Wed Nov 18 20:07:43 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 15:07:43 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
Message-ID: <564CDA8F.9020303@oracle.com>

If the value is "too big" and no atomicity has been requested (via 
use-site volatile indication, declaration-site indication, etc), then 
tearing is possible.  If atomicity is requested, the VM is free to pick 
the most efficient means to transparently achieve this, whether this be 
atomic load/store, seq lock, spin lock, Java lock, boxing, etc.

On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
> This is good to hear Brian.
>
>     So the answer is not "reads and writes need to be atomic", but
>     instead "there should be a way to ask for atomic reads/writes." 
>     The current front-runner here builds on an existing story -- using
>     volatile to make longs/double fields atomic.  We can easily extend
>     this to values. 
>
>
> Just to spitball this a bit, if the value type is larger than max 
> atomic transfer unit on the machine, what's the thinking? I suppose 
> you'd need some locking, but where would it get a lock for this? Would 
> a synthetic one be generated automatically (javac or JVM)?
>
> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>
>>     If value types are final, that means the array-store and
>>     array-load have to be atomic in some way for fast-flow to work,
>>     i.e., mark has to be written last and read first in the
>>     structured array.
>>
>
>     That would be putting it too strongly.
>
>     Your concern is structure tearing.  If thread A writes a value to
>     an array element (or a field) and thread B reads it, you are
>     concerned that the reader see some consistent value that was put
>     there by a single write in the past (even if stale.)
>
>     Obviously for "small enough" values, this isn't an issue, but
>     small enough is pretty small (64 bits on today's hardware).   Also
>     note that the JLS / JVMS have allowed tearing of longs and doubles
>     since day one, unless they are declared volatile.
>
>     Note that the bad outcome -- tearing -- /only happens in the
>     presence of a data race/.  So the question is, what should we do
>     to protect the too-clever (and too-unclever) folks from their own
>     mistakes?  The answer is certainly not to make all value reads and
>     writes atomics -- this would be burdening all of the users who
>     follow the rules with a crippling performance penalty (and it is
>     really bad for larger-than-64-bit values) for the sake of the few
>     who are living on the edge.
>
>     So the answer is not "reads and writes need to be atomic", but
>     instead "there should be a way to ask for atomic reads/writes." 
>     The current front-runner here builds on an existing story -- using
>     volatile to make longs/double fields atomic.  We can easily extend
>     this to values.
>
>     That leaves two cases uncovered:
>      - What about arrays -- there is currently no means to declare an
>     array with volatile (or final) elements.  This is being explored now.
>      - What about classes that are intrinsically security-sensitive,
>     and could not tolerate tearing in any case?  For this case, we are
>     considering a declaration-site indication that a value is
>     "unbreakable".
>
>     Summary:
>      - Tearing is going to be a risk when accessing shared mutable
>     state via a data race.
>      - There will be use-site and likely also declaration-site tools
>     to opt into atomicity, with a cost.
>
>
>


From Mohammad.Rezaei at gs.com  Wed Nov 18 20:11:20 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Wed, 18 Nov 2015 15:11:20 -0500
Subject: Sentinels in collections, was RE: Primitive Queue<any T>
	considerations
Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>

Many primitive collections use sentinels *without* requiring removal of those in the collection. This is done by storing a bit of side information. For example, for a set of int, GS Collections uses 0 and 1 as sentinels (meaning empty and removed, respectively). Every call to methods like get/contains/add/etc first checks to see if the value is a sentinel, and if so, queries/updates the side data. For a set, the side data is tiny and trivial: there is a single byte that encode if the set contains 0, 1, both or none.

Thanks
Moh

>-----Original Message-----
>From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net] On Behalf Of
>Vitaly Davidovich
>Sent: Wednesday, November 18, 2015 2:31 PM
>To: Richard Warburton
>Cc: valhalla-dev at openjdk.java.net
>Subject: Re: Primitive Queue<any T> considerations
>
>Although I agree that sometimes a sentinel or even an entire range of
>values is available to indicate absence, I don't think it's the right
>answer to the question.  In particular, if you're writing a general purpose
>collection, you cannot expect your users to remove one possible value from
>their universe to signal absence.  The collections that do this today are
>simply working around lack of nullable primitives.
>
>On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
>richard.warburton at gmail.com> wrote:
>
>> Hi,
>>
>> I'm not sure about the default null-indicator because every time a queue is
>> > needed in our library, that can serve a source with unique choice of a
>> > default-null value. It is unlikely the users of the library want or can
>> > specify that all the time.
>> >
>>
>> I appreciate that this is diverging directly form your language related
>> question, but it is pertinent to writing anyfied collections using
>> Valhalla. My experience using primitive specialised collections is that it
>> has always been possible to have a sentinel value, though obviously my
>> experience won't necessary reflect that of every single person in the Java
>> community. It isn't always appropriate for it to be 0, which is what I
>> think T.default is currently going to return for primitives and when I've
>> done primitive specialised collections before they allow you to specify the
>> missing value sentinel.
>>
>> Have you got of an actual genuine use case where a sentinel value doesn't
>> work well, rather than a theoretical "hey, maybe you want to have a set
>> that contains every possible int?"
>>
>> regards,
>>
>>   Richard Warburton
>>
>>   http://insightfullogic.com
>>   @RichardWarburto <http://twitter.com/richardwarburto>
>>

From peter.levart at gmail.com  Wed Nov 18 20:16:11 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Nov 2015 21:16:11 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
Message-ID: <564CDC8B.6050604@gmail.com>



On 11/18/2015 07:55 PM, Vitaly Davidovich wrote:
> As discussed upthread, how would that operation be atomic for arbitrarily
> sized value types?

Not atomic, but for SPSC queue discussed here and for the price of 
doubling the writes, this problem could be solved like:

array[offset] = Cell(value, 0);
UNSAFE.storeFence();
array[offset] = Cell(value, 1);
producerIndex++;


Maybe JIT could even detect such pattern and try to optimize it doing 
something equivalent but not expressible:

array[offset].value = value;
UNSAFE.storeFence();
array[offset].mark = 1;
producerIndex++;



Regards, Peter

> On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy Management) <
> duncan.macgregor at ge.com> wrote:
>
>> On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
>> <valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com>
>> wrote:
>>
>>> Let's assume I have a value type named cell:
>>>
>>> valuetype Cell<any T> {
>>>    public T value;
>>>    public int mark;
>>> }
>>>
>>> and a power-of-2 array of cells:
>>>
>>> Cell<any T>[] array;
>>>
>>>
>>> having Cell with final fields is useless here because then I have a
>>> constant array and not a queue.
>> Maybe I?m not following you here but the fact fields on a Cell are final
>> does not stop you from replacing one Cell in array with a new Cell, just
>> as you can replace individual ints in an array of ints.
>>
>> So you offset method would be more like
>>
>> offset = producerIndex & (array.length - 1)
>> if (array[offset].mark != 0) {
>>      return false;
>> }
>> array[offset] = Cell(value, 1);
>> producerIndex++;
>>
>> return true;
>>
>> And that operation on the array will be guaranteed to be atomic (though
>> probably needs a compare and swap in case another thread is trying to do
>> the same thing).
>>
>> Duncan.
>>
>>


From vitalyd at gmail.com  Wed Nov 18 20:16:52 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 15:16:52 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CDA8F.9020303@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
Message-ID: <CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>

Right, I was talking about case where atomicity is explicitly requested.  I
understand JVM can pick, I'm curious on where it would get a lock from.
I'm also unclear how boxing helps since the data has to be unpacked
atomically anyway.

Using David's example, say he wanted to have queue of nullable longs, which
internally he'd store as Optional<long>.  But how does he specify in his
generic class definition that when sizeof (Optional<T>) > word size that
he'd like atomic access? This goes back to specialization selection, but
has size constraint.

sent from my phone
On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> If the value is "too big" and no atomicity has been requested (via
> use-site volatile indication, declaration-site indication, etc), then
> tearing is possible.  If atomicity is requested, the VM is free to pick the
> most efficient means to transparently achieve this, whether this be atomic
> load/store, seq lock, spin lock, Java lock, boxing, etc.
>
> On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>
> This is good to hear Brian.
>
> So the answer is not "reads and writes need to be atomic", but instead
>> "there should be a way to ask for atomic reads/writes."  The current
>> front-runner here builds on an existing story -- using volatile to make
>> longs/double fields atomic.  We can easily extend this to values.
>
>
> Just to spitball this a bit, if the value type is larger than max atomic
> transfer unit on the machine, what's the thinking? I suppose you'd need
> some locking, but where would it get a lock for this? Would a synthetic one
> be generated automatically (javac or JVM)?
>
> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>>
>> If value types are final, that means the array-store and array-load have
>> to be atomic in some way for fast-flow to work, i.e., mark has to be
>> written last and read first in the structured array.
>>
>>
>> That would be putting it too strongly.
>>
>> Your concern is structure tearing.  If thread A writes a value to an
>> array element (or a field) and thread B reads it, you are concerned that
>> the reader see some consistent value that was put there by a single write
>> in the past (even if stale.)
>>
>> Obviously for "small enough" values, this isn't an issue, but small
>> enough is pretty small (64 bits on today's hardware).   Also note that the
>> JLS / JVMS have allowed tearing of longs and doubles since day one, unless
>> they are declared volatile.
>>
>> Note that the bad outcome -- tearing -- *only happens in the presence of
>> a data race*.  So the question is, what should we do to protect the
>> too-clever (and too-unclever) folks from their own mistakes?  The answer is
>> certainly not to make all value reads and writes atomics -- this would be
>> burdening all of the users who follow the rules with a crippling
>> performance penalty (and it is really bad for larger-than-64-bit values)
>> for the sake of the few who are living on the edge.
>>
>> So the answer is not "reads and writes need to be atomic", but instead
>> "there should be a way to ask for atomic reads/writes."  The current
>> front-runner here builds on an existing story -- using volatile to make
>> longs/double fields atomic.  We can easily extend this to values.
>>
>> That leaves two cases uncovered:
>>  - What about arrays -- there is currently no means to declare an array
>> with volatile (or final) elements.  This is being explored now.
>>  - What about classes that are intrinsically security-sensitive, and
>> could not tolerate tearing in any case?  For this case, we are considering
>> a declaration-site indication that a value is "unbreakable".
>>
>> Summary:
>>  - Tearing is going to be a risk when accessing shared mutable state via
>> a data race.
>>  - There will be use-site and likely also declaration-site tools to opt
>> into atomicity, with a cost.
>>
>>
>>
>
>

From brian.goetz at oracle.com  Wed Nov 18 20:24:45 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 15:24:45 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
Message-ID: <564CDE8D.1040308@oracle.com>


On 11/18/2015 3:16 PM, Vitaly Davidovich wrote:
>
> Right, I was talking about case where atomicity is explicitly 
> requested.  I understand JVM can pick, I'm curious on where it would 
> get a lock from.  I'm also unclear how boxing helps since the data has 
> to be unpacked atomically anyway.
>

The lock used would be invisible to the calling code.  Lots of degrees 
of freedom for the VM here, of course.  If transactional memory ever 
starts working well enough, that's an option as well.

Converting an array of big values to an array of boxes (transparently) 
is one of the options the VM has regardless of atomicity requirements.  
For big values, passing them by value is expensive anyway, and the VM 
has the right to silently box and pass a reference instead if it thinks 
this will be faster (this will be invisible to the user.)  An array of 
boxes has the nice property in that references are small enough that 
atomicity is free. So one way to get atomicity for an array of 1000-bit 
values is to use an array of references to boxed values.  Again, VM's 
choice.

> Using David's example, say he wanted to have queue of nullable longs, 
> which internally he'd store as Optional<long>.  But how does he 
> specify in his generic class definition that when sizeof (Optional<T>) 
> > word size that he'd like atomic access? This goes back to 
> specialization selection, but has size constraint.
>

Nullability is orthogonal to atomicity.  If he wants nullability, he 
wraps his values with Optional<T>.  (For refs, Optional<T> will 
hopefully be the same size as a ref, so it isn't a problem to do this 
across the board.)

For atomicity, you don't switch on size, you just ask for it.  If the 
values are small, atomicity will be free or cheap anyway.


> sent from my phone
>
> On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     If the value is "too big" and no atomicity has been requested (via
>     use-site volatile indication, declaration-site indication, etc),
>     then tearing is possible.  If atomicity is requested, the VM is
>     free to pick the most efficient means to transparently achieve
>     this, whether this be atomic load/store, seq lock, spin lock, Java
>     lock, boxing, etc.
>
>     On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>     This is good to hear Brian.
>>
>>         So the answer is not "reads and writes need to be atomic",
>>         but instead "there should be a way to ask for atomic
>>         reads/writes." The current front-runner here builds on an
>>         existing story -- using volatile to make longs/double fields
>>         atomic.  We can easily extend this to values. 
>>
>>
>>     Just to spitball this a bit, if the value type is larger than max
>>     atomic transfer unit on the machine, what's the thinking? I
>>     suppose you'd need some locking, but where would it get a lock
>>     for this? Would a synthetic one be generated automatically (javac
>>     or JVM)?
>>
>>     On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz
>>     <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>>
>>
>>>         If value types are final, that means the array-store and
>>>         array-load have to be atomic in some way for fast-flow to
>>>         work, i.e., mark has to be written last and read first in
>>>         the structured array.
>>>
>>
>>         That would be putting it too strongly.
>>
>>         Your concern is structure tearing.  If thread A writes a
>>         value to an array element (or a field) and thread B reads it,
>>         you are concerned that the reader see some consistent value
>>         that was put there by a single write in the past (even if
>>         stale.)
>>
>>         Obviously for "small enough" values, this isn't an issue, but
>>         small enough is pretty small (64 bits on today's hardware).  
>>         Also note that the JLS / JVMS have allowed tearing of longs
>>         and doubles since day one, unless they are declared volatile.
>>
>>         Note that the bad outcome -- tearing -- /only happens in the
>>         presence of a data race/.  So the question is, what should we
>>         do to protect the too-clever (and too-unclever) folks from
>>         their own mistakes?  The answer is certainly not to make all
>>         value reads and writes atomics -- this would be burdening all
>>         of the users who follow the rules with a crippling
>>         performance penalty (and it is really bad for
>>         larger-than-64-bit values) for the sake of the few who are
>>         living on the edge.
>>
>>         So the answer is not "reads and writes need to be atomic",
>>         but instead "there should be a way to ask for atomic
>>         reads/writes."  The current front-runner here builds on an
>>         existing story -- using volatile to make longs/double fields
>>         atomic.  We can easily extend this to values.
>>
>>         That leaves two cases uncovered:
>>          - What about arrays -- there is currently no means to
>>         declare an array with volatile (or final) elements.  This is
>>         being explored now.
>>          - What about classes that are intrinsically
>>         security-sensitive, and could not tolerate tearing in any
>>         case?  For this case, we are considering a declaration-site
>>         indication that a value is "unbreakable".
>>
>>         Summary:
>>          - Tearing is going to be a risk when accessing shared
>>         mutable state via a data race.
>>          - There will be use-site and likely also declaration-site
>>         tools to opt into atomicity, with a cost.
>>
>>
>>
>


From akarnokd at gmail.com  Wed Nov 18 20:25:49 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 21:25:49 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
Message-ID: <CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>

In my queue case, I'm not worried about payload tearing but rather memory
reordering around the mark field. The analogy is the classical concurrency
quiz question:

Thread A:

a = 42;
b = 1;

Thread B:

if (b == 1)
   println(a);


If b is volatile or is accessed with Unsafe.getVolatile and putOrdered then
it doesn't matter how large a is or in what order a's structure is updated
as long as it stops and flushes when b is set to 1.

If the valuetype is immutable and assignment is memcopy then b can't be
part of that structure and has to be a separate array of int at least (if
no byte-atomics). The two arrays can now be anywhere in memory and if one
wants to avoid false sharing, the memory usage increases as well. On a
sidenote, without knowing the size of a, it's hard to pad the array to
avoid false sharing between adjacent elements.


2015-11-18 20:57 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:

> FWIW, CLR explicitly states that value type assignments larger than machine
> word size are not atomic.  Or rather, it guarantees that any value type of
> size <= machine word will be atomic (modulo someone playing around with
> struct layout manually).  As far as I know, there's never been much fuss
> about this stipulation.
>
> On Wed, Nov 18, 2015 at 2:15 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
> wrote:
>
> > Hi,
> >
> >
> >
> > That?s a good question. How would arbitrary-sized values be assigned into
> > an array without any other thread observing the value halfway between two
> > states with its invariants not holding?
> >
> >
> >
> > As is mentioned in the JLS in 17.6: ?One consideration for
> implementations
> > of the Java Virtual Machine is that every field and array element is
> > considered distinct; updates to one field or element must not interact
> with
> > reads or updates of any other field or element.? This probably has to be
> > weakened in the same way as non-atomic reads/writes of long.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
> > Windows 10
> >
> >
> >
> >
> >
> >
> > *From: *Vitaly Davidovich
> > *Sent: *Wednesday, November 18, 2015 19:56
> > *To: *MacGregor, Duncan (GE Energy Management)
> > *Cc: *valhalla-dev at openjdk.java.net
> > *Subject: *Re: Primitive Queue considerations
> >
> >
> >
> >
> >
> > As discussed upthread, how would that operation be atomic for arbitrarily
> >
> > sized value types?
> >
> >
> >
> > On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy
> Management) <
> >
> > duncan.macgregor at ge.com> wrote:
> >
> >
> >
> > >
> >
> > >
> >
> > > On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
> >
> > > <valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com
> >
> >
> > > wrote:
> >
> > >
> >
> > > >Let's assume I have a value type named cell:
> >
> > > >
> >
> > > >valuetype Cell<any T> {
> >
> > > >   public T value;
> >
> > > >   public int mark;
> >
> > > >}
> >
> > > >
> >
> > > >and a power-of-2 array of cells:
> >
> > > >
> >
> > > >Cell<any T>[] array;
> >
> > > >
> >
> > > >
> >
> > > >having Cell with final fields is useless here because then I have a
> >
> > > >constant array and not a queue.
> >
> > >
> >
> > > Maybe I?m not following you here but the fact fields on a Cell are
> final
> >
> > > does not stop you from replacing one Cell in array with a new Cell,
> just
> >
> > > as you can replace individual ints in an array of ints.
> >
> > >
> >
> > > So you offset method would be more like
> >
> > >
> >
> > > offset = producerIndex & (array.length - 1)
> >
> > > if (array[offset].mark != 0) {
> >
> > >     return false;
> >
> > > }
> >
> > > array[offset] = Cell(value, 1);
> >
> > > producerIndex++;
> >
> > >
> >
> > > return true;
> >
> > >
> >
> > > And that operation on the array will be guaranteed to be atomic (though
> >
> > > probably needs a compare and swap in case another thread is trying to
> do
> >
> > > the same thing).
> >
> > >
> >
> > > Duncan.
> >
> > >
> >
> > >
> >
> >
> >
> >
> >
>



-- 
Best regards,
David Karnok

From vitalyd at gmail.com  Wed Nov 18 20:29:45 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 15:29:45 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CDC8B.6050604@gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564CDC8B.6050604@gmail.com>
Message-ID: <CAHjP37FsHQ8UL_PNuG7nSz1qkMAi5V-wG01-1xmtFHS7P5Eepg@mail.gmail.com>

Please no! :)

What if I have 6 fields? 7 fields? 15 fields?

On Wed, Nov 18, 2015 at 3:16 PM, Peter Levart <peter.levart at gmail.com>
wrote:

>
>
> On 11/18/2015 07:55 PM, Vitaly Davidovich wrote:
>
> As discussed upthread, how would that operation be atomic for arbitrarily
> sized value types?
>
>
> Not atomic, but for SPSC queue discussed here and for the price of
> doubling the writes, this problem could be solved like:
>
> array[offset] = Cell(value, 0);
> UNSAFE.storeFence();
> array[offset] = Cell(value, 1);
> producerIndex++;
>
>
> Maybe JIT could even detect such pattern and try to optimize it doing
> something equivalent but not expressible:
>
> array[offset].value = value;
> UNSAFE.storeFence();
> array[offset].mark = 1;
> producerIndex++;
>
>
>
> Regards, Peter
>
>
> On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy Management) <duncan.macgregor at ge.com> wrote:
>
>
> On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"<valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com> <valhalla-dev-bounces at openjdk.java.netonbehalfofakarnokd@gmail.com>
> wrote:
>
>
> Let's assume I have a value type named cell:
>
> valuetype Cell<any T> {
>   public T value;
>   public int mark;
> }
>
> and a power-of-2 array of cells:
>
> Cell<any T>[] array;
>
>
> having Cell with final fields is useless here because then I have a
> constant array and not a queue.
>
> Maybe I?m not following you here but the fact fields on a Cell are final
> does not stop you from replacing one Cell in array with a new Cell, just
> as you can replace individual ints in an array of ints.
>
> So you offset method would be more like
>
> offset = producerIndex & (array.length - 1)
> if (array[offset].mark != 0) {
>     return false;
> }
> array[offset] = Cell(value, 1);
> producerIndex++;
>
> return true;
>
> And that operation on the array will be guaranteed to be atomic (though
> probably needs a compare and swap in case another thread is trying to do
> the same thing).
>
> Duncan.
>
>
>
>
>

From brian.goetz at oracle.com  Wed Nov 18 20:36:50 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 15:36:50 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
	<CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
Message-ID: <564CE162.2010107@oracle.com>

In this respect, large values offer nothing new over longs and doubles.  
In the presence of a data race, tearing and reordering is possible.  
Reads and writes of values have the same JMM characteristics as any 
other read or write.

Note that while values are in part about getting flatter data layouts, 
we do not plan to offer anything in the way of fine-grained layout 
control, such as allowing for explicit alignment requirements.  (Though 
other efforts, such as Project Panama, may have something to offer here).

On 11/18/2015 3:25 PM, D?vid Karnok wrote:
> In my queue case, I'm not worried about payload tearing but rather memory
> reordering around the mark field. The analogy is the classical concurrency
> quiz question:
>
> Thread A:
>
> a = 42;
> b = 1;
>
> Thread B:
>
> if (b == 1)
>     println(a);
>
>
> If b is volatile or is accessed with Unsafe.getVolatile and putOrdered then
> it doesn't matter how large a is or in what order a's structure is updated
> as long as it stops and flushes when b is set to 1.
>
> If the valuetype is immutable and assignment is memcopy then b can't be
> part of that structure and has to be a separate array of int at least (if
> no byte-atomics). The two arrays can now be anywhere in memory and if one
> wants to avoid false sharing, the memory usage increases as well. On a
> sidenote, without knowing the size of a, it's hard to pad the array to
> avoid false sharing between adjacent elements.
>
>
> 2015-11-18 20:57 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:
>
>> FWIW, CLR explicitly states that value type assignments larger than machine
>> word size are not atomic.  Or rather, it guarantees that any value type of
>> size <= machine word will be atomic (modulo someone playing around with
>> struct layout manually).  As far as I know, there's never been much fuss
>> about this stipulation.
>>
>> On Wed, Nov 18, 2015 at 2:15 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> That?s a good question. How would arbitrary-sized values be assigned into
>>> an array without any other thread observing the value halfway between two
>>> states with its invariants not holding?
>>>
>>>
>>>
>>> As is mentioned in the JLS in 17.6: ?One consideration for
>> implementations
>>> of the Java Virtual Machine is that every field and array element is
>>> considered distinct; updates to one field or element must not interact
>> with
>>> reads or updates of any other field or element.? This probably has to be
>>> weakened in the same way as non-atomic reads/writes of long.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Vitaly Davidovich
>>> *Sent: *Wednesday, November 18, 2015 19:56
>>> *To: *MacGregor, Duncan (GE Energy Management)
>>> *Cc: *valhalla-dev at openjdk.java.net
>>> *Subject: *Re: Primitive Queue considerations
>>>
>>>
>>>
>>>
>>>
>>> As discussed upthread, how would that operation be atomic for arbitrarily
>>>
>>> sized value types?
>>>
>>>
>>>
>>> On Wed, Nov 18, 2015 at 1:53 PM, MacGregor, Duncan (GE Energy
>> Management) <
>>> duncan.macgregor at ge.com> wrote:
>>>
>>>
>>>
>>>> On 18/11/2015, 16:22, "valhalla-dev on behalf of D?vid Karnok"
>>>> <valhalla-dev-bounces at openjdk.java.net on behalf of akarnokd at gmail.com
>>>
>>>> wrote:
>>>>> Let's assume I have a value type named cell:
>>>>> valuetype Cell<any T> {
>>>>>    public T value;
>>>>>    public int mark;
>>>>> }
>>>>> and a power-of-2 array of cells:
>>>>> Cell<any T>[] array;
>>>>> having Cell with final fields is useless here because then I have a
>>>>> constant array and not a queue.
>>>> Maybe I?m not following you here but the fact fields on a Cell are
>> final
>>>> does not stop you from replacing one Cell in array with a new Cell,
>> just
>>>> as you can replace individual ints in an array of ints.
>>>> So you offset method would be more like
>>>> offset = producerIndex & (array.length - 1)
>>>> if (array[offset].mark != 0) {
>>>>      return false;
>>>> }
>>>> array[offset] = Cell(value, 1);
>>>> producerIndex++;
>>>> return true;
>>>> And that operation on the array will be guaranteed to be atomic (though
>>>> probably needs a compare and swap in case another thread is trying to
>> do
>>>> the same thing).
>>>> Duncan.
>>>
>>>
>>>
>>>
>
>


From vitalyd at gmail.com  Wed Nov 18 20:38:21 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 15:38:21 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CDE8D.1040308@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
Message-ID: <CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>

>
> Converting an array of big values to an array of boxes (transparently) is
> one of the options the VM has regardless of atomicity requirements.  For
> big values, passing them by value is expensive anyway, and the VM has the
> right to silently box and pass a reference instead if it thinks this will
> be faster (this will be invisible to the user.)  An array of boxes has the
> nice property in that references are small enough that atomicity is free.
> So one way to get atomicity for an array of 1000-bit values is to use an
> array of references to boxed values.  Again, VM's choice.


I know we discussed this automatic boxing before, and I still think it's a
bad idea to do this behind the user's back.  A large point of value types
is they do not touch the heap, and thus do not contribute to any subsequent
GC pauses.  If I had a large struct, I may be just fine having a slower
copy operation percolating through the stack.  This is like escape
analysis, nobody that's avoiding GC is actually relying on it because of
this "VM's choice" aspect.  I urge you to reconsider this automatic boxing
aspect.  Nobody is going to complain that the JVM is not automatically
boxing their large struct, but someone will complain if there's heap
allocation behind the scenes.

Nullability is orthogonal to atomicity.  If he wants nullability, he wraps
> his values with Optional<T>.  (For refs, Optional<T> will hopefully be the
> same size as a ref, so it isn't a problem to do this across the board.)
> For atomicity, you don't switch on size, you just ask for it.  If the
> values are small, atomicity will be free or cheap anyway.


Well, if there's going to be a way to request just atomicity (and not
ordering as well), which will nop if size is atomic natively, then great.
Otherwise, I'd hate for there to be *any* performance penalty if the size
is <= word size.

On Wed, Nov 18, 2015 at 3:24 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>
> On 11/18/2015 3:16 PM, Vitaly Davidovich wrote:
>
> Right, I was talking about case where atomicity is explicitly requested.
> I understand JVM can pick, I'm curious on where it would get a lock from.
> I'm also unclear how boxing helps since the data has to be unpacked
> atomically anyway.
>
>
> The lock used would be invisible to the calling code.  Lots of degrees of
> freedom for the VM here, of course.  If transactional memory ever starts
> working well enough, that's an option as well.
>
> Converting an array of big values to an array of boxes (transparently) is
> one of the options the VM has regardless of atomicity requirements.  For
> big values, passing them by value is expensive anyway, and the VM has the
> right to silently box and pass a reference instead if it thinks this will
> be faster (this will be invisible to the user.)  An array of boxes has the
> nice property in that references are small enough that atomicity is free.
> So one way to get atomicity for an array of 1000-bit values is to use an
> array of references to boxed values.  Again, VM's choice.
>
> Using David's example, say he wanted to have queue of nullable longs,
> which internally he'd store as Optional<long>.  But how does he specify in
> his generic class definition that when sizeof (Optional<T>) > word size
> that he'd like atomic access? This goes back to specialization selection,
> but has size constraint.
>
>
> Nullability is orthogonal to atomicity.  If he wants nullability, he wraps
> his values with Optional<T>.  (For refs, Optional<T> will hopefully be the
> same size as a ref, so it isn't a problem to do this across the board.)
>
> For atomicity, you don't switch on size, you just ask for it.  If the
> values are small, atomicity will be free or cheap anyway.
>
>
> sent from my phone
> On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
>> If the value is "too big" and no atomicity has been requested (via
>> use-site volatile indication, declaration-site indication, etc), then
>> tearing is possible.  If atomicity is requested, the VM is free to pick the
>> most efficient means to transparently achieve this, whether this be atomic
>> load/store, seq lock, spin lock, Java lock, boxing, etc.
>>
>> On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>
>> This is good to hear Brian.
>>
>> So the answer is not "reads and writes need to be atomic", but instead
>>> "there should be a way to ask for atomic reads/writes."  The current
>>> front-runner here builds on an existing story -- using volatile to make
>>> longs/double fields atomic.  We can easily extend this to values.
>>
>>
>> Just to spitball this a bit, if the value type is larger than max atomic
>> transfer unit on the machine, what's the thinking? I suppose you'd need
>> some locking, but where would it get a lock for this? Would a synthetic one
>> be generated automatically (javac or JVM)?
>>
>> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz < <brian.goetz at oracle.com>
>> brian.goetz at oracle.com> wrote:
>>
>>>
>>> If value types are final, that means the array-store and array-load have
>>> to be atomic in some way for fast-flow to work, i.e., mark has to be
>>> written last and read first in the structured array.
>>>
>>>
>>> That would be putting it too strongly.
>>>
>>> Your concern is structure tearing.  If thread A writes a value to an
>>> array element (or a field) and thread B reads it, you are concerned that
>>> the reader see some consistent value that was put there by a single write
>>> in the past (even if stale.)
>>>
>>> Obviously for "small enough" values, this isn't an issue, but small
>>> enough is pretty small (64 bits on today's hardware).   Also note that the
>>> JLS / JVMS have allowed tearing of longs and doubles since day one, unless
>>> they are declared volatile.
>>>
>>> Note that the bad outcome -- tearing -- *only happens in the presence
>>> of a data race*.  So the question is, what should we do to protect the
>>> too-clever (and too-unclever) folks from their own mistakes?  The answer is
>>> certainly not to make all value reads and writes atomics -- this would be
>>> burdening all of the users who follow the rules with a crippling
>>> performance penalty (and it is really bad for larger-than-64-bit values)
>>> for the sake of the few who are living on the edge.
>>>
>>> So the answer is not "reads and writes need to be atomic", but instead
>>> "there should be a way to ask for atomic reads/writes."  The current
>>> front-runner here builds on an existing story -- using volatile to make
>>> longs/double fields atomic.  We can easily extend this to values.
>>>
>>> That leaves two cases uncovered:
>>>  - What about arrays -- there is currently no means to declare an array
>>> with volatile (or final) elements.  This is being explored now.
>>>  - What about classes that are intrinsically security-sensitive, and
>>> could not tolerate tearing in any case?  For this case, we are considering
>>> a declaration-site indication that a value is "unbreakable".
>>>
>>> Summary:
>>>  - Tearing is going to be a risk when accessing shared mutable state via
>>> a data race.
>>>  - There will be use-site and likely also declaration-site tools to opt
>>> into atomicity, with a cost.
>>>
>>>
>>>
>>
>>
>

From akarnokd at gmail.com  Wed Nov 18 20:38:53 2015
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 18 Nov 2015 21:38:53 +0100
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
Message-ID: <CAAWwtm9W7TT-w064yRDSt1=diKntVAyLbO4E9purCCDmwknyeA@mail.gmail.com>

To be clear, I don't want to use nullable primitive long, this is what Long
is for. My problem is that the j.u.Queue.poll() relies on the ability to
return null indicating an empty queue which when primitivized is likely to
return zero which is also a valid value.

A similar issue happens with JDBC's getInt() method which may return zero
and one has to call wasNull() to find out if it was a valid zero or a null
really.

With ref-based queue, I can forbid using null as a value but it would be
over restrictive to forbid zero in offer().

This means that for Spsc, the usage pattern of

T v = queue.poll();
if (v != null) { ... }

has to be changed to

if (!queue.isEmpty()) {
    T v = queue.poll();
    ...
}

Which incurs 2 cache misses with fast-flow and 3 with the marked variant.

Note however that this pattern doesn't work for MPMC as another consumer
may take the value between isEmpty and poll.

The bottom line is that my SPSC queue requires a different API to tell
apart emptyness and having a value "atomically" and the ability to chose
this implementation in an <any T> situation.


2015-11-18 21:16 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:

> Right, I was talking about case where atomicity is explicitly requested.
> I understand JVM can pick, I'm curious on where it would get a lock from.
> I'm also unclear how boxing helps since the data has to be unpacked
> atomically anyway.
>
> Using David's example, say he wanted to have queue of nullable longs,
> which internally he'd store as Optional<long>.  But how does he specify in
> his generic class definition that when sizeof (Optional<T>) > word size
> that he'd like atomic access? This goes back to specialization selection,
> but has size constraint.
>
> sent from my phone
> On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
>> If the value is "too big" and no atomicity has been requested (via
>> use-site volatile indication, declaration-site indication, etc), then
>> tearing is possible.  If atomicity is requested, the VM is free to pick the
>> most efficient means to transparently achieve this, whether this be atomic
>> load/store, seq lock, spin lock, Java lock, boxing, etc.
>>
>> On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>
>> This is good to hear Brian.
>>
>> So the answer is not "reads and writes need to be atomic", but instead
>>> "there should be a way to ask for atomic reads/writes."  The current
>>> front-runner here builds on an existing story -- using volatile to make
>>> longs/double fields atomic.  We can easily extend this to values.
>>
>>
>> Just to spitball this a bit, if the value type is larger than max atomic
>> transfer unit on the machine, what's the thinking? I suppose you'd need
>> some locking, but where would it get a lock for this? Would a synthetic one
>> be generated automatically (javac or JVM)?
>>
>> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>>
>>> If value types are final, that means the array-store and array-load have
>>> to be atomic in some way for fast-flow to work, i.e., mark has to be
>>> written last and read first in the structured array.
>>>
>>>
>>> That would be putting it too strongly.
>>>
>>> Your concern is structure tearing.  If thread A writes a value to an
>>> array element (or a field) and thread B reads it, you are concerned that
>>> the reader see some consistent value that was put there by a single write
>>> in the past (even if stale.)
>>>
>>> Obviously for "small enough" values, this isn't an issue, but small
>>> enough is pretty small (64 bits on today's hardware).   Also note that the
>>> JLS / JVMS have allowed tearing of longs and doubles since day one, unless
>>> they are declared volatile.
>>>
>>> Note that the bad outcome -- tearing -- *only happens in the presence
>>> of a data race*.  So the question is, what should we do to protect the
>>> too-clever (and too-unclever) folks from their own mistakes?  The answer is
>>> certainly not to make all value reads and writes atomics -- this would be
>>> burdening all of the users who follow the rules with a crippling
>>> performance penalty (and it is really bad for larger-than-64-bit values)
>>> for the sake of the few who are living on the edge.
>>>
>>> So the answer is not "reads and writes need to be atomic", but instead
>>> "there should be a way to ask for atomic reads/writes."  The current
>>> front-runner here builds on an existing story -- using volatile to make
>>> longs/double fields atomic.  We can easily extend this to values.
>>>
>>> That leaves two cases uncovered:
>>>  - What about arrays -- there is currently no means to declare an array
>>> with volatile (or final) elements.  This is being explored now.
>>>  - What about classes that are intrinsically security-sensitive, and
>>> could not tolerate tearing in any case?  For this case, we are considering
>>> a declaration-site indication that a value is "unbreakable".
>>>
>>> Summary:
>>>  - Tearing is going to be a risk when accessing shared mutable state via
>>> a data race.
>>>  - There will be use-site and likely also declaration-site tools to opt
>>> into atomicity, with a cost.
>>>
>>>
>>>
>>
>>


-- 
Best regards,
David Karnok

From vitalyd at gmail.com  Wed Nov 18 20:43:19 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 15:43:19 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm9W7TT-w064yRDSt1=diKntVAyLbO4E9purCCDmwknyeA@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<CAAWwtm9W7TT-w064yRDSt1=diKntVAyLbO4E9purCCDmwknyeA@mail.gmail.com>
Message-ID: <CAHjP37HVwBgyzU+NEz1S2PE6e0Fzm1BQkOZ8Gt+q-hyQg-vzbw@mail.gmail.com>

>
> To be clear, I don't want to use nullable primitive long, this is what
> Long is for


Why would you want to use Long if you have Nullable<long> available? That
doesn't make sense given your counting of cache misses.

T v = queue.poll();
> if (v != null) { ... }



has to be changed to



if (!queue.isEmpty()) {
>     T v = queue.poll();
>     ...
> }


The usage pattern ought to become:

Optional<T> v = queue.poll();
// use Optional API to work with v



On Wed, Nov 18, 2015 at 3:38 PM, D?vid Karnok <akarnokd at gmail.com> wrote:

> To be clear, I don't want to use nullable primitive long, this is what
> Long is for. My problem is that the j.u.Queue.poll() relies on the ability
> to return null indicating an empty queue which when primitivized is likely
> to return zero which is also a valid value.
>
> A similar issue happens with JDBC's getInt() method which may return zero
> and one has to call wasNull() to find out if it was a valid zero or a null
> really.
>
> With ref-based queue, I can forbid using null as a value but it would be
> over restrictive to forbid zero in offer().
>
> This means that for Spsc, the usage pattern of
>
> T v = queue.poll();
> if (v != null) { ... }
>
> has to be changed to
>
> if (!queue.isEmpty()) {
>     T v = queue.poll();
>     ...
> }
>
> Which incurs 2 cache misses with fast-flow and 3 with the marked variant.
>
> Note however that this pattern doesn't work for MPMC as another consumer
> may take the value between isEmpty and poll.
>
> The bottom line is that my SPSC queue requires a different API to tell
> apart emptyness and having a value "atomically" and the ability to chose
> this implementation in an <any T> situation.
>
>
> 2015-11-18 21:16 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:
>
>> Right, I was talking about case where atomicity is explicitly requested.
>> I understand JVM can pick, I'm curious on where it would get a lock from.
>> I'm also unclear how boxing helps since the data has to be unpacked
>> atomically anyway.
>>
>> Using David's example, say he wanted to have queue of nullable longs,
>> which internally he'd store as Optional<long>.  But how does he specify in
>> his generic class definition that when sizeof (Optional<T>) > word size
>> that he'd like atomic access? This goes back to specialization selection,
>> but has size constraint.
>>
>> sent from my phone
>> On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>>
>>> If the value is "too big" and no atomicity has been requested (via
>>> use-site volatile indication, declaration-site indication, etc), then
>>> tearing is possible.  If atomicity is requested, the VM is free to pick the
>>> most efficient means to transparently achieve this, whether this be atomic
>>> load/store, seq lock, spin lock, Java lock, boxing, etc.
>>>
>>> On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>>
>>> This is good to hear Brian.
>>>
>>> So the answer is not "reads and writes need to be atomic", but instead
>>>> "there should be a way to ask for atomic reads/writes."  The current
>>>> front-runner here builds on an existing story -- using volatile to make
>>>> longs/double fields atomic.  We can easily extend this to values.
>>>
>>>
>>> Just to spitball this a bit, if the value type is larger than max atomic
>>> transfer unit on the machine, what's the thinking? I suppose you'd need
>>> some locking, but where would it get a lock for this? Would a synthetic one
>>> be generated automatically (javac or JVM)?
>>>
>>> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com>
>>> wrote:
>>>
>>>>
>>>> If value types are final, that means the array-store and array-load
>>>> have to be atomic in some way for fast-flow to work, i.e., mark has to be
>>>> written last and read first in the structured array.
>>>>
>>>>
>>>> That would be putting it too strongly.
>>>>
>>>> Your concern is structure tearing.  If thread A writes a value to an
>>>> array element (or a field) and thread B reads it, you are concerned that
>>>> the reader see some consistent value that was put there by a single write
>>>> in the past (even if stale.)
>>>>
>>>> Obviously for "small enough" values, this isn't an issue, but small
>>>> enough is pretty small (64 bits on today's hardware).   Also note that the
>>>> JLS / JVMS have allowed tearing of longs and doubles since day one, unless
>>>> they are declared volatile.
>>>>
>>>> Note that the bad outcome -- tearing -- *only happens in the presence
>>>> of a data race*.  So the question is, what should we do to protect the
>>>> too-clever (and too-unclever) folks from their own mistakes?  The answer is
>>>> certainly not to make all value reads and writes atomics -- this would be
>>>> burdening all of the users who follow the rules with a crippling
>>>> performance penalty (and it is really bad for larger-than-64-bit values)
>>>> for the sake of the few who are living on the edge.
>>>>
>>>> So the answer is not "reads and writes need to be atomic", but instead
>>>> "there should be a way to ask for atomic reads/writes."  The current
>>>> front-runner here builds on an existing story -- using volatile to make
>>>> longs/double fields atomic.  We can easily extend this to values.
>>>>
>>>> That leaves two cases uncovered:
>>>>  - What about arrays -- there is currently no means to declare an array
>>>> with volatile (or final) elements.  This is being explored now.
>>>>  - What about classes that are intrinsically security-sensitive, and
>>>> could not tolerate tearing in any case?  For this case, we are considering
>>>> a declaration-site indication that a value is "unbreakable".
>>>>
>>>> Summary:
>>>>  - Tearing is going to be a risk when accessing shared mutable state
>>>> via a data race.
>>>>  - There will be use-site and likely also declaration-site tools to opt
>>>> into atomicity, with a cost.
>>>>
>>>>
>>>>
>>>
>>>
>
>
> --
> Best regards,
> David Karnok
>

From brian.goetz at oracle.com  Wed Nov 18 20:45:36 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 15:45:36 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
Message-ID: <564CE370.7060306@oracle.com>

Your sense of "what people are not going to complain about" is woefully 
optimistic :)

On 11/18/2015 3:38 PM, Vitaly Davidovich wrote:
>
>     Converting an array of big values to an array of boxes
>     (transparently) is one of the options the VM has regardless of
>     atomicity requirements.  For big values, passing them by value is
>     expensive anyway, and the VM has the right to silently box and
>     pass a reference instead if it thinks this will be faster (this
>     will be invisible to the user.)  An array of boxes has the nice
>     property in that references are small enough that atomicity is
>     free. So one way to get atomicity for an array of 1000-bit values
>     is to use an array of references to boxed values.  Again, VM's
>     choice. 
>
>
> I know we discussed this automatic boxing before, and I still think 
> it's a bad idea to do this behind the user's back.  A large point of 
> value types is they do not touch the heap, and thus do not contribute 
> to any subsequent GC pauses. If I had a large struct, I may be just 
> fine having a slower copy operation percolating through the stack.  
> This is like escape analysis, nobody that's avoiding GC is actually 
> relying on it because of this "VM's choice" aspect.  I urge you to 
> reconsider this automatic boxing aspect.  Nobody is going to complain 
> that the JVM is not automatically boxing their large struct, but 
> someone will complain if there's heap allocation behind the scenes.
>
>     Nullability is orthogonal to atomicity.  If he wants nullability,
>     he wraps his values with Optional<T>.  (For refs, Optional<T> will
>     hopefully be the same size as a ref, so it isn't a problem to do
>     this across the board.)
>     For atomicity, you don't switch on size, you just ask for it.  If
>     the values are small, atomicity will be free or cheap anyway.
>
>
> Well, if there's going to be a way to request just atomicity (and not 
> ordering as well), which will nop if size is atomic natively, then 
> great.  Otherwise, I'd hate for there to be *any* performance penalty 
> if the size is <= word size.
>
> On Wed, Nov 18, 2015 at 3:24 PM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>
>     On 11/18/2015 3:16 PM, Vitaly Davidovich wrote:
>>
>>     Right, I was talking about case where atomicity is explicitly
>>     requested.  I understand JVM can pick, I'm curious on where it
>>     would get a lock from.  I'm also unclear how boxing helps since
>>     the data has to be unpacked atomically anyway.
>>
>
>     The lock used would be invisible to the calling code.  Lots of
>     degrees of freedom for the VM here, of course.  If transactional
>     memory ever starts working well enough, that's an option as well.
>
>     Converting an array of big values to an array of boxes
>     (transparently) is one of the options the VM has regardless of
>     atomicity requirements.  For big values, passing them by value is
>     expensive anyway, and the VM has the right to silently box and
>     pass a reference instead if it thinks this will be faster (this
>     will be invisible to the user.)  An array of boxes has the nice
>     property in that references are small enough that atomicity is
>     free. So one way to get atomicity for an array of 1000-bit values
>     is to use an array of references to boxed values. Again, VM's choice.
>
>>     Using David's example, say he wanted to have queue of nullable
>>     longs, which internally he'd store as Optional<long>.  But how
>>     does he specify in his generic class definition that when sizeof
>>     (Optional<T>) > word size that he'd like atomic access? This goes
>>     back to specialization selection, but has size constraint.
>>
>
>     Nullability is orthogonal to atomicity.  If he wants nullability,
>     he wraps his values with Optional<T>.  (For refs, Optional<T> will
>     hopefully be the same size as a ref, so it isn't a problem to do
>     this across the board.)
>
>     For atomicity, you don't switch on size, you just ask for it.  If
>     the values are small, atomicity will be free or cheap anyway.
>
>
>>     sent from my phone
>>
>>     On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com
>>     <mailto:brian.goetz at oracle.com>> wrote:
>>
>>         If the value is "too big" and no atomicity has been requested
>>         (via use-site volatile indication, declaration-site
>>         indication, etc), then tearing is possible.  If atomicity is
>>         requested, the VM is free to pick the most efficient means to
>>         transparently achieve this, whether this be atomic
>>         load/store, seq lock, spin lock, Java lock, boxing, etc.
>>
>>         On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>>         This is good to hear Brian.
>>>
>>>             So the answer is not "reads and writes need to be
>>>             atomic", but instead "there should be a way to ask for
>>>             atomic reads/writes." The current front-runner here
>>>             builds on an existing story -- using volatile to make
>>>             longs/double fields atomic.  We can easily extend this
>>>             to values. 
>>>
>>>
>>>         Just to spitball this a bit, if the value type is larger
>>>         than max atomic transfer unit on the machine, what's the
>>>         thinking? I suppose you'd need some locking, but where would
>>>         it get a lock for this? Would a synthetic one be generated
>>>         automatically (javac or JVM)?
>>>
>>>         On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz
>>>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>
>>>>             If value types are final, that means the array-store
>>>>             and array-load have to be atomic in some way for
>>>>             fast-flow to work, i.e., mark has to be written last
>>>>             and read first in the structured array.
>>>>
>>>
>>>             That would be putting it too strongly.
>>>
>>>             Your concern is structure tearing.  If thread A writes a
>>>             value to an array element (or a field) and thread B
>>>             reads it, you are concerned that the reader see some
>>>             consistent value that was put there by a single write in
>>>             the past (even if stale.)
>>>
>>>             Obviously for "small enough" values, this isn't an
>>>             issue, but small enough is pretty small (64 bits on
>>>             today's hardware).   Also note that the JLS / JVMS have
>>>             allowed tearing of longs and doubles since day one,
>>>             unless they are declared volatile.
>>>
>>>             Note that the bad outcome -- tearing -- /only happens in
>>>             the presence of a data race/.  So the question is, what
>>>             should we do to protect the too-clever (and
>>>             too-unclever) folks from their own mistakes?  The answer
>>>             is certainly not to make all value reads and writes
>>>             atomics -- this would be burdening all of the users who
>>>             follow the rules with a crippling performance penalty
>>>             (and it is really bad for larger-than-64-bit values) for
>>>             the sake of the few who are living on the edge.
>>>
>>>             So the answer is not "reads and writes need to be
>>>             atomic", but instead "there should be a way to ask for
>>>             atomic reads/writes."  The current front-runner here
>>>             builds on an existing story -- using volatile to make
>>>             longs/double fields atomic.  We can easily extend this
>>>             to values.
>>>
>>>             That leaves two cases uncovered:
>>>              - What about arrays -- there is currently no means to
>>>             declare an array with volatile (or final) elements. This
>>>             is being explored now.
>>>              - What about classes that are intrinsically
>>>             security-sensitive, and could not tolerate tearing in
>>>             any case?  For this case, we are considering a
>>>             declaration-site indication that a value is "unbreakable".
>>>
>>>             Summary:
>>>              - Tearing is going to be a risk when accessing shared
>>>             mutable state via a data race.
>>>              - There will be use-site and likely also
>>>             declaration-site tools to opt into atomicity, with a cost.
>>>
>>>
>>>
>>
>
>


From vitalyd at gmail.com  Wed Nov 18 20:51:10 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 15:51:10 -0500
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>

This may work for a set, but doesn't necessarily generalize to any data
structure.  Moreover, you're now checking the argument for being one of the
two sentinels on all these operations.  There are times when side data or
out-of-band data is warranted, but those occasions should be dictated by
things other than lack of efficiently expressing a nullable primitive.

On Wed, Nov 18, 2015 at 3:11 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com
> wrote:

> Many primitive collections use sentinels *without* requiring removal of
> those in the collection. This is done by storing a bit of side information.
> For example, for a set of int, GS Collections uses 0 and 1 as sentinels
> (meaning empty and removed, respectively). Every call to methods like
> get/contains/add/etc first checks to see if the value is a sentinel, and if
> so, queries/updates the side data. For a set, the side data is tiny and
> trivial: there is a single byte that encode if the set contains 0, 1, both
> or none.
>
> Thanks
> Moh
>
> >-----Original Message-----
> >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net] On
> Behalf Of
> >Vitaly Davidovich
> >Sent: Wednesday, November 18, 2015 2:31 PM
> >To: Richard Warburton
> >Cc: valhalla-dev at openjdk.java.net
> >Subject: Re: Primitive Queue<any T> considerations
> >
> >Although I agree that sometimes a sentinel or even an entire range of
> >values is available to indicate absence, I don't think it's the right
> >answer to the question.  In particular, if you're writing a general
> purpose
> >collection, you cannot expect your users to remove one possible value from
> >their universe to signal absence.  The collections that do this today are
> >simply working around lack of nullable primitives.
> >
> >On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
> >richard.warburton at gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I'm not sure about the default null-indicator because every time a
> queue is
> >> > needed in our library, that can serve a source with unique choice of a
> >> > default-null value. It is unlikely the users of the library want or
> can
> >> > specify that all the time.
> >> >
> >>
> >> I appreciate that this is diverging directly form your language related
> >> question, but it is pertinent to writing anyfied collections using
> >> Valhalla. My experience using primitive specialised collections is that
> it
> >> has always been possible to have a sentinel value, though obviously my
> >> experience won't necessary reflect that of every single person in the
> Java
> >> community. It isn't always appropriate for it to be 0, which is what I
> >> think T.default is currently going to return for primitives and when
> I've
> >> done primitive specialised collections before they allow you to specify
> the
> >> missing value sentinel.
> >>
> >> Have you got of an actual genuine use case where a sentinel value
> doesn't
> >> work well, rather than a theoretical "hey, maybe you want to have a set
> >> that contains every possible int?"
> >>
> >> regards,
> >>
> >>   Richard Warburton
> >>
> >>   http://insightfullogic.com
> >>   @RichardWarburto <http://twitter.com/richardwarburto>
> >>
>

From brian.goetz at oracle.com  Wed Nov 18 20:52:52 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 18 Nov 2015 15:52:52 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAAWwtm9W7TT-w064yRDSt1=diKntVAyLbO4E9purCCDmwknyeA@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<CAAWwtm9W7TT-w064yRDSt1=diKntVAyLbO4E9purCCDmwknyeA@mail.gmail.com>
Message-ID: <564CE524.8090807@oracle.com>



On 11/18/2015 3:38 PM, D?vid Karnok wrote:
> To be clear, I don't want to use nullable primitive long, this is what 
> Long is for.

There's a big difference between these two ... a Long will entail an 
indirection (as well as 2x as much memory), an Optional<long> will not.  
If boxes were good enough here, we'd not need to do values...

> My problem is that the j.u.Queue.poll() relies on the ability to 
> return null indicating an empty queue which when primitivized is 
> likely to return zero which is also a valid value.

Ah, now I get it -- you're talking about APIs, not implementation.

Since null is not a member of all types, then methods like Queue.poll() 
(and Map.get() !) are not candidates for naive any-fication.  We have a 
story here for binary- and source-compatible migration of such APIs to 
new Optional-bearing methods while leaving the old "broken" methods in 
place for compatibility with existing erased ref instantiations.  We've 
alluded to this briefly in State of the Specialization.  Details to be 
forthcoming.


From vitalyd at gmail.com  Wed Nov 18 21:03:07 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 16:03:07 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CE370.7060306@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<564CE370.7060306@oracle.com>
Message-ID: <CAHjP37G2MDGQReqwzOdQpVKKFxqeVpcOw6Q61aTABodj3HVUqg@mail.gmail.com>

Do a poll if you'd like :) Bottom line is that (reasonable) people will not
complain if (a) the JVM behavior is predictable and (b) it does what the
programmer requested.  Given the topic is value types, and one of the big
issues they help with is avoiding the heap, people *will* complain if
that's subverted behind the scenes.  For once, don't make the JVM think it
knows better :).

On Wed, Nov 18, 2015 at 3:45 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Your sense of "what people are not going to complain about" is woefully
> optimistic :)
>
> On 11/18/2015 3:38 PM, Vitaly Davidovich wrote:
>
> Converting an array of big values to an array of boxes (transparently) is
>> one of the options the VM has regardless of atomicity requirements.  For
>> big values, passing them by value is expensive anyway, and the VM has the
>> right to silently box and pass a reference instead if it thinks this will
>> be faster (this will be invisible to the user.)  An array of boxes has the
>> nice property in that references are small enough that atomicity is free.
>> So one way to get atomicity for an array of 1000-bit values is to use an
>> array of references to boxed values.  Again, VM's choice.
>
>
> I know we discussed this automatic boxing before, and I still think it's a
> bad idea to do this behind the user's back.  A large point of value types
> is they do not touch the heap, and thus do not contribute to any subsequent
> GC pauses.  If I had a large struct, I may be just fine having a slower
> copy operation percolating through the stack.  This is like escape
> analysis, nobody that's avoiding GC is actually relying on it because of
> this "VM's choice" aspect.  I urge you to reconsider this automatic boxing
> aspect.  Nobody is going to complain that the JVM is not automatically
> boxing their large struct, but someone will complain if there's heap
> allocation behind the scenes.
>
> Nullability is orthogonal to atomicity.  If he wants nullability, he wraps
>> his values with Optional<T>.  (For refs, Optional<T> will hopefully be the
>> same size as a ref, so it isn't a problem to do this across the board.)
>> For atomicity, you don't switch on size, you just ask for it.  If the
>> values are small, atomicity will be free or cheap anyway.
>
>
> Well, if there's going to be a way to request just atomicity (and not
> ordering as well), which will nop if size is atomic natively, then great.
> Otherwise, I'd hate for there to be *any* performance penalty if the size
> is <= word size.
>
> On Wed, Nov 18, 2015 at 3:24 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>>
>> On 11/18/2015 3:16 PM, Vitaly Davidovich wrote:
>>
>> Right, I was talking about case where atomicity is explicitly requested.
>> I understand JVM can pick, I'm curious on where it would get a lock from.
>> I'm also unclear how boxing helps since the data has to be unpacked
>> atomically anyway.
>>
>>
>> The lock used would be invisible to the calling code.  Lots of degrees of
>> freedom for the VM here, of course.  If transactional memory ever starts
>> working well enough, that's an option as well.
>>
>> Converting an array of big values to an array of boxes (transparently) is
>> one of the options the VM has regardless of atomicity requirements.  For
>> big values, passing them by value is expensive anyway, and the VM has the
>> right to silently box and pass a reference instead if it thinks this will
>> be faster (this will be invisible to the user.)  An array of boxes has the
>> nice property in that references are small enough that atomicity is free.
>> So one way to get atomicity for an array of 1000-bit values is to use an
>> array of references to boxed values.  Again, VM's choice.
>>
>> Using David's example, say he wanted to have queue of nullable longs,
>> which internally he'd store as Optional<long>.  But how does he specify in
>> his generic class definition that when sizeof (Optional<T>) > word size
>> that he'd like atomic access? This goes back to specialization selection,
>> but has size constraint.
>>
>>
>> Nullability is orthogonal to atomicity.  If he wants nullability, he
>> wraps his values with Optional<T>.  (For refs, Optional<T> will hopefully
>> be the same size as a ref, so it isn't a problem to do this across the
>> board.)
>>
>> For atomicity, you don't switch on size, you just ask for it.  If the
>> values are small, atomicity will be free or cheap anyway.
>>
>>
>> sent from my phone
>> On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>>
>>> If the value is "too big" and no atomicity has been requested (via
>>> use-site volatile indication, declaration-site indication, etc), then
>>> tearing is possible.  If atomicity is requested, the VM is free to pick the
>>> most efficient means to transparently achieve this, whether this be atomic
>>> load/store, seq lock, spin lock, Java lock, boxing, etc.
>>>
>>> On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>>
>>> This is good to hear Brian.
>>>
>>> So the answer is not "reads and writes need to be atomic", but instead
>>>> "there should be a way to ask for atomic reads/writes."  The current
>>>> front-runner here builds on an existing story -- using volatile to make
>>>> longs/double fields atomic.  We can easily extend this to values.
>>>
>>>
>>> Just to spitball this a bit, if the value type is larger than max atomic
>>> transfer unit on the machine, what's the thinking? I suppose you'd need
>>> some locking, but where would it get a lock for this? Would a synthetic one
>>> be generated automatically (javac or JVM)?
>>>
>>> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com>
>>> wrote:
>>>
>>>>
>>>> If value types are final, that means the array-store and array-load
>>>> have to be atomic in some way for fast-flow to work, i.e., mark has to be
>>>> written last and read first in the structured array.
>>>>
>>>>
>>>> That would be putting it too strongly.
>>>>
>>>> Your concern is structure tearing.  If thread A writes a value to an
>>>> array element (or a field) and thread B reads it, you are concerned that
>>>> the reader see some consistent value that was put there by a single write
>>>> in the past (even if stale.)
>>>>
>>>> Obviously for "small enough" values, this isn't an issue, but small
>>>> enough is pretty small (64 bits on today's hardware).   Also note that the
>>>> JLS / JVMS have allowed tearing of longs and doubles since day one, unless
>>>> they are declared volatile.
>>>>
>>>> Note that the bad outcome -- tearing -- *only happens in the presence
>>>> of a data race*.  So the question is, what should we do to protect the
>>>> too-clever (and too-unclever) folks from their own mistakes?  The answer is
>>>> certainly not to make all value reads and writes atomics -- this would be
>>>> burdening all of the users who follow the rules with a crippling
>>>> performance penalty (and it is really bad for larger-than-64-bit values)
>>>> for the sake of the few who are living on the edge.
>>>>
>>>> So the answer is not "reads and writes need to be atomic", but instead
>>>> "there should be a way to ask for atomic reads/writes."  The current
>>>> front-runner here builds on an existing story -- using volatile to make
>>>> longs/double fields atomic.  We can easily extend this to values.
>>>>
>>>> That leaves two cases uncovered:
>>>>  - What about arrays -- there is currently no means to declare an array
>>>> with volatile (or final) elements.  This is being explored now.
>>>>  - What about classes that are intrinsically security-sensitive, and
>>>> could not tolerate tearing in any case?  For this case, we are considering
>>>> a declaration-site indication that a value is "unbreakable".
>>>>
>>>> Summary:
>>>>  - Tearing is going to be a risk when accessing shared mutable state
>>>> via a data race.
>>>>  - There will be use-site and likely also declaration-site tools to opt
>>>> into atomicity, with a cost.
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

From vitalyd at gmail.com  Wed Nov 18 21:13:24 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 16:13:24 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37G2MDGQReqwzOdQpVKKFxqeVpcOw6Q61aTABodj3HVUqg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<564CE370.7060306@oracle.com>
	<CAHjP37G2MDGQReqwzOdQpVKKFxqeVpcOw6Q61aTABodj3HVUqg@mail.gmail.com>
Message-ID: <CAHjP37E2G0nek0ttq0Vt8Hw+5r6hHEcio5Qq6Chw7DGf5qPxSQ@mail.gmail.com>

... and of course, if the user wants boxing for their fat struct, they can
add the box themselves in code.  Conversely, I presumably cannot tell the
JVM to stop autoboxing on my behalf (unless this will be some flag, but
let's not add any more flags).  Spend your JVM optimization budget on
something more worthwhile please :).

On Wed, Nov 18, 2015 at 4:03 PM, Vitaly Davidovich <vitalyd at gmail.com>
wrote:

> Do a poll if you'd like :) Bottom line is that (reasonable) people will
> not complain if (a) the JVM behavior is predictable and (b) it does what
> the programmer requested.  Given the topic is value types, and one of the
> big issues they help with is avoiding the heap, people *will* complain if
> that's subverted behind the scenes.  For once, don't make the JVM think it
> knows better :).
>
> On Wed, Nov 18, 2015 at 3:45 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Your sense of "what people are not going to complain about" is woefully
>> optimistic :)
>>
>> On 11/18/2015 3:38 PM, Vitaly Davidovich wrote:
>>
>> Converting an array of big values to an array of boxes (transparently) is
>>> one of the options the VM has regardless of atomicity requirements.  For
>>> big values, passing them by value is expensive anyway, and the VM has the
>>> right to silently box and pass a reference instead if it thinks this will
>>> be faster (this will be invisible to the user.)  An array of boxes has the
>>> nice property in that references are small enough that atomicity is free.
>>> So one way to get atomicity for an array of 1000-bit values is to use an
>>> array of references to boxed values.  Again, VM's choice.
>>
>>
>> I know we discussed this automatic boxing before, and I still think it's
>> a bad idea to do this behind the user's back.  A large point of value types
>> is they do not touch the heap, and thus do not contribute to any subsequent
>> GC pauses.  If I had a large struct, I may be just fine having a slower
>> copy operation percolating through the stack.  This is like escape
>> analysis, nobody that's avoiding GC is actually relying on it because of
>> this "VM's choice" aspect.  I urge you to reconsider this automatic boxing
>> aspect.  Nobody is going to complain that the JVM is not automatically
>> boxing their large struct, but someone will complain if there's heap
>> allocation behind the scenes.
>>
>> Nullability is orthogonal to atomicity.  If he wants nullability, he
>>> wraps his values with Optional<T>.  (For refs, Optional<T> will hopefully
>>> be the same size as a ref, so it isn't a problem to do this across the
>>> board.)
>>> For atomicity, you don't switch on size, you just ask for it.  If the
>>> values are small, atomicity will be free or cheap anyway.
>>
>>
>> Well, if there's going to be a way to request just atomicity (and not
>> ordering as well), which will nop if size is atomic natively, then great.
>> Otherwise, I'd hate for there to be *any* performance penalty if the size
>> is <= word size.
>>
>> On Wed, Nov 18, 2015 at 3:24 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>>
>>> On 11/18/2015 3:16 PM, Vitaly Davidovich wrote:
>>>
>>> Right, I was talking about case where atomicity is explicitly
>>> requested.  I understand JVM can pick, I'm curious on where it would get a
>>> lock from.  I'm also unclear how boxing helps since the data has to be
>>> unpacked atomically anyway.
>>>
>>>
>>> The lock used would be invisible to the calling code.  Lots of degrees
>>> of freedom for the VM here, of course.  If transactional memory ever starts
>>> working well enough, that's an option as well.
>>>
>>> Converting an array of big values to an array of boxes (transparently)
>>> is one of the options the VM has regardless of atomicity requirements.  For
>>> big values, passing them by value is expensive anyway, and the VM has the
>>> right to silently box and pass a reference instead if it thinks this will
>>> be faster (this will be invisible to the user.)  An array of boxes has the
>>> nice property in that references are small enough that atomicity is free.
>>> So one way to get atomicity for an array of 1000-bit values is to use an
>>> array of references to boxed values.  Again, VM's choice.
>>>
>>> Using David's example, say he wanted to have queue of nullable longs,
>>> which internally he'd store as Optional<long>.  But how does he specify in
>>> his generic class definition that when sizeof (Optional<T>) > word size
>>> that he'd like atomic access? This goes back to specialization selection,
>>> but has size constraint.
>>>
>>>
>>> Nullability is orthogonal to atomicity.  If he wants nullability, he
>>> wraps his values with Optional<T>.  (For refs, Optional<T> will hopefully
>>> be the same size as a ref, so it isn't a problem to do this across the
>>> board.)
>>>
>>> For atomicity, you don't switch on size, you just ask for it.  If the
>>> values are small, atomicity will be free or cheap anyway.
>>>
>>>
>>> sent from my phone
>>> On Nov 18, 2015 3:07 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>>>
>>>> If the value is "too big" and no atomicity has been requested (via
>>>> use-site volatile indication, declaration-site indication, etc), then
>>>> tearing is possible.  If atomicity is requested, the VM is free to pick the
>>>> most efficient means to transparently achieve this, whether this be atomic
>>>> load/store, seq lock, spin lock, Java lock, boxing, etc.
>>>>
>>>> On 11/18/2015 3:01 PM, Vitaly Davidovich wrote:
>>>>
>>>> This is good to hear Brian.
>>>>
>>>> So the answer is not "reads and writes need to be atomic", but instead
>>>>> "there should be a way to ask for atomic reads/writes."  The current
>>>>> front-runner here builds on an existing story -- using volatile to make
>>>>> longs/double fields atomic.  We can easily extend this to values.
>>>>
>>>>
>>>> Just to spitball this a bit, if the value type is larger than max
>>>> atomic transfer unit on the machine, what's the thinking? I suppose you'd
>>>> need some locking, but where would it get a lock for this? Would a
>>>> synthetic one be generated automatically (javac or JVM)?
>>>>
>>>> On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com>
>>>> wrote:
>>>>
>>>>>
>>>>> If value types are final, that means the array-store and array-load
>>>>> have to be atomic in some way for fast-flow to work, i.e., mark has to be
>>>>> written last and read first in the structured array.
>>>>>
>>>>>
>>>>> That would be putting it too strongly.
>>>>>
>>>>> Your concern is structure tearing.  If thread A writes a value to an
>>>>> array element (or a field) and thread B reads it, you are concerned that
>>>>> the reader see some consistent value that was put there by a single write
>>>>> in the past (even if stale.)
>>>>>
>>>>> Obviously for "small enough" values, this isn't an issue, but small
>>>>> enough is pretty small (64 bits on today's hardware).   Also note that the
>>>>> JLS / JVMS have allowed tearing of longs and doubles since day one, unless
>>>>> they are declared volatile.
>>>>>
>>>>> Note that the bad outcome -- tearing -- *only happens in the presence
>>>>> of a data race*.  So the question is, what should we do to protect
>>>>> the too-clever (and too-unclever) folks from their own mistakes?  The
>>>>> answer is certainly not to make all value reads and writes atomics -- this
>>>>> would be burdening all of the users who follow the rules with a crippling
>>>>> performance penalty (and it is really bad for larger-than-64-bit values)
>>>>> for the sake of the few who are living on the edge.
>>>>>
>>>>> So the answer is not "reads and writes need to be atomic", but instead
>>>>> "there should be a way to ask for atomic reads/writes."  The current
>>>>> front-runner here builds on an existing story -- using volatile to make
>>>>> longs/double fields atomic.  We can easily extend this to values.
>>>>>
>>>>> That leaves two cases uncovered:
>>>>>  - What about arrays -- there is currently no means to declare an
>>>>> array with volatile (or final) elements.  This is being explored now.
>>>>>  - What about classes that are intrinsically security-sensitive, and
>>>>> could not tolerate tearing in any case?  For this case, we are considering
>>>>> a declaration-site indication that a value is "unbreakable".
>>>>>
>>>>> Summary:
>>>>>  - Tearing is going to be a risk when accessing shared mutable state
>>>>> via a data race.
>>>>>  - There will be use-site and likely also declaration-site tools to
>>>>> opt into atomicity, with a cost.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

From Mohammad.Rezaei at gs.com  Wed Nov 18 21:18:39 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Wed, 18 Nov 2015 16:18:39 -0500
Subject: Sentinels in collections, was RE: Primitive Queue<any T>
	considerations
In-Reply-To: <CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>

It?s not ?lack of efficiently expressing a nullable primitive?. It?s a need for one or more sentinel values. (Please note that I changed the subject because this is a very different concern from the original thread, where the return value required something special.) The sentinels in this thread are entirely internal and completely invisible to the user and the API. Sentinel values are also prevalent in plain object collections, where creating a sentinel is easy because reference equality can be guaranteed to be false for an object that?s visible only to the data structure. For example, UnifiedMap in GS collections has two object sentinels (NULL_KEY and CHAINED_KEY) as well as null (meaning empty). ConcurrentHashMap in GS collections has 4 sentinels (RESIZE_SENTINEL, RESIZED, RESIZING and null). TObjectHash from Trove uses two sentinels (REMOVED and FREE).

The checking against 0/1 is far faster than losing a byte (and possibly more due to alignment) for every entry or having a header or having a bit set, etc.

Sentinels are useful for many collections that use arrays to store stuff. Node based collections generally need one sentinel, the terminal node (and they cannot be implemented with values as proposed here due to the self-referential nature of such structures).

Thanks
Moh

From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Wednesday, November 18, 2015 3:51 PM
To: Rezaei, Mohammad A. [Tech]
Cc: Richard Warburton; valhalla-dev at openjdk.java.net
Subject: Re: Sentinels in collections, was RE: Primitive Queue<any T> considerations

This may work for a set, but doesn't necessarily generalize to any data structure.  Moreover, you're now checking the argument for being one of the two sentinels on all these operations.  There are times when side data or out-of-band data is warranted, but those occasions should be dictated by things other than lack of efficiently expressing a nullable primitive.

On Wed, Nov 18, 2015 at 3:11 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com<mailto:Mohammad.Rezaei at gs.com>> wrote:
Many primitive collections use sentinels *without* requiring removal of those in the collection. This is done by storing a bit of side information. For example, for a set of int, GS Collections uses 0 and 1 as sentinels (meaning empty and removed, respectively). Every call to methods like get/contains/add/etc first checks to see if the value is a sentinel, and if so, queries/updates the side data. For a set, the side data is tiny and trivial: there is a single byte that encode if the set contains 0, 1, both or none.

Thanks
Moh

>-----Original Message-----
>From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net<mailto:valhalla-dev-bounces at openjdk.java.net>] On Behalf Of
>Vitaly Davidovich
>Sent: Wednesday, November 18, 2015 2:31 PM
>To: Richard Warburton
>Cc: valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>
>Subject: Re: Primitive Queue<any T> considerations
>
>Although I agree that sometimes a sentinel or even an entire range of
>values is available to indicate absence, I don't think it's the right
>answer to the question.  In particular, if you're writing a general purpose
>collection, you cannot expect your users to remove one possible value from
>their universe to signal absence.  The collections that do this today are
>simply working around lack of nullable primitives.
>
>On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
>richard.warburton at gmail.com<mailto:richard.warburton at gmail.com>> wrote:
>
>> Hi,
>>
>> I'm not sure about the default null-indicator because every time a queue is
>> > needed in our library, that can serve a source with unique choice of a
>> > default-null value. It is unlikely the users of the library want or can
>> > specify that all the time.
>> >
>>
>> I appreciate that this is diverging directly form your language related
>> question, but it is pertinent to writing anyfied collections using
>> Valhalla. My experience using primitive specialised collections is that it
>> has always been possible to have a sentinel value, though obviously my
>> experience won't necessary reflect that of every single person in the Java
>> community. It isn't always appropriate for it to be 0, which is what I
>> think T.default is currently going to return for primitives and when I've
>> done primitive specialised collections before they allow you to specify the
>> missing value sentinel.
>>
>> Have you got of an actual genuine use case where a sentinel value doesn't
>> work well, rather than a theoretical "hey, maybe you want to have a set
>> that contains every possible int?"
>>
>> regards,
>>
>>   Richard Warburton
>>
>>   http://insightfullogic.com
>>   @RichardWarburto <http://twitter.com/richardwarburto>
>>


From vitalyd at gmail.com  Wed Nov 18 21:28:02 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 16:28:02 -0500
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>

If your point is that *internal* sentinels are useful, sure, no
disagreement.  But the sentinels we were talking about in the other thread
are taken out of the user's domain of values, are not purely internal, and
no side data is desired.

On Wed, Nov 18, 2015 at 4:18 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com
> wrote:

> It?s not ?lack of efficiently expressing a nullable primitive?. It?s a
> need for one or more sentinel values. (Please note that I changed the
> subject because this is a very different concern from the original thread,
> where the return value required something special.) The sentinels in this
> thread are entirely internal and completely invisible to the user and the
> API. Sentinel values are also prevalent in plain object collections, where
> creating a sentinel is easy because reference equality can be guaranteed to
> be false for an object that?s visible only to the data structure. For
> example, UnifiedMap in GS collections has two object sentinels (NULL_KEY
> and CHAINED_KEY) as well as null (meaning empty). ConcurrentHashMap in GS
> collections has 4 sentinels (RESIZE_SENTINEL, RESIZED, RESIZING and null).
> TObjectHash from Trove uses two sentinels (REMOVED and FREE).
>
>
>
> The checking against 0/1 is far faster than losing a byte (and possibly
> more due to alignment) for every entry or having a header or having a bit
> set, etc.
>
>
>
> Sentinels are useful for many collections that use arrays to store stuff.
> Node based collections generally need one sentinel, the terminal node (and
> they cannot be implemented with values as proposed here due to the
> self-referential nature of such structures).
>
>
>
> Thanks
>
> Moh
>
>
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Wednesday, November 18, 2015 3:51 PM
> *To:* Rezaei, Mohammad A. [Tech]
> *Cc:* Richard Warburton; valhalla-dev at openjdk.java.net
> *Subject:* Re: Sentinels in collections, was RE: Primitive Queue<any T>
> considerations
>
>
>
> This may work for a set, but doesn't necessarily generalize to any data
> structure.  Moreover, you're now checking the argument for being one of the
> two sentinels on all these operations.  There are times when side data or
> out-of-band data is warranted, but those occasions should be dictated by
> things other than lack of efficiently expressing a nullable primitive.
>
>
>
> On Wed, Nov 18, 2015 at 3:11 PM, Rezaei, Mohammad A. <
> Mohammad.Rezaei at gs.com> wrote:
>
> Many primitive collections use sentinels *without* requiring removal of
> those in the collection. This is done by storing a bit of side information.
> For example, for a set of int, GS Collections uses 0 and 1 as sentinels
> (meaning empty and removed, respectively). Every call to methods like
> get/contains/add/etc first checks to see if the value is a sentinel, and if
> so, queries/updates the side data. For a set, the side data is tiny and
> trivial: there is a single byte that encode if the set contains 0, 1, both
> or none.
>
> Thanks
> Moh
>
> >-----Original Message-----
> >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net] On
> Behalf Of
> >Vitaly Davidovich
> >Sent: Wednesday, November 18, 2015 2:31 PM
> >To: Richard Warburton
> >Cc: valhalla-dev at openjdk.java.net
> >Subject: Re: Primitive Queue<any T> considerations
> >
> >Although I agree that sometimes a sentinel or even an entire range of
> >values is available to indicate absence, I don't think it's the right
> >answer to the question.  In particular, if you're writing a general
> purpose
> >collection, you cannot expect your users to remove one possible value from
> >their universe to signal absence.  The collections that do this today are
> >simply working around lack of nullable primitives.
> >
> >On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
> >richard.warburton at gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I'm not sure about the default null-indicator because every time a
> queue is
> >> > needed in our library, that can serve a source with unique choice of a
> >> > default-null value. It is unlikely the users of the library want or
> can
> >> > specify that all the time.
> >> >
> >>
> >> I appreciate that this is diverging directly form your language related
> >> question, but it is pertinent to writing anyfied collections using
> >> Valhalla. My experience using primitive specialised collections is that
> it
> >> has always been possible to have a sentinel value, though obviously my
> >> experience won't necessary reflect that of every single person in the
> Java
> >> community. It isn't always appropriate for it to be 0, which is what I
> >> think T.default is currently going to return for primitives and when
> I've
> >> done primitive specialised collections before they allow you to specify
> the
> >> missing value sentinel.
> >>
> >> Have you got of an actual genuine use case where a sentinel value
> doesn't
> >> work well, rather than a theoretical "hey, maybe you want to have a set
> >> that contains every possible int?"
> >>
> >> regards,
> >>
> >>   Richard Warburton
> >>
> >>   http://insightfullogic.com
> >>   @RichardWarburto <http://twitter.com/richardwarburto>
> >>
>
>
>

From Mohammad.Rezaei at gs.com  Wed Nov 18 21:33:10 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Wed, 18 Nov 2015 16:33:10 -0500
Subject: Sentinels in collections, was RE: Primitive Queue<any T>
	considerations
In-Reply-To: <CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>

Agreed, so maybe I misinterpreted Richard?s email (I tried to mitigate by changing the subject). Richard, which type of sentinel did you mean?

Thanks
Moh

From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Wednesday, November 18, 2015 4:28 PM
To: Rezaei, Mohammad A. [Tech]
Cc: Richard Warburton; valhalla-dev at openjdk.java.net
Subject: Re: Sentinels in collections, was RE: Primitive Queue<any T> considerations

If your point is that *internal* sentinels are useful, sure, no disagreement.  But the sentinels we were talking about in the other thread are taken out of the user's domain of values, are not purely internal, and no side data is desired.

On Wed, Nov 18, 2015 at 4:18 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com<mailto:Mohammad.Rezaei at gs.com>> wrote:
It?s not ?lack of efficiently expressing a nullable primitive?. It?s a need for one or more sentinel values. (Please note that I changed the subject because this is a very different concern from the original thread, where the return value required something special.) The sentinels in this thread are entirely internal and completely invisible to the user and the API. Sentinel values are also prevalent in plain object collections, where creating a sentinel is easy because reference equality can be guaranteed to be false for an object that?s visible only to the data structure. For example, UnifiedMap in GS collections has two object sentinels (NULL_KEY and CHAINED_KEY) as well as null (meaning empty). ConcurrentHashMap in GS collections has 4 sentinels (RESIZE_SENTINEL, RESIZED, RESIZING and null). TObjectHash from Trove uses two sentinels (REMOVED and FREE).

The checking against 0/1 is far faster than losing a byte (and possibly more due to alignment) for every entry or having a header or having a bit set, etc.

Sentinels are useful for many collections that use arrays to store stuff. Node based collections generally need one sentinel, the terminal node (and they cannot be implemented with values as proposed here due to the self-referential nature of such structures).

Thanks
Moh

From: Vitaly Davidovich [mailto:vitalyd at gmail.com<mailto:vitalyd at gmail.com>]
Sent: Wednesday, November 18, 2015 3:51 PM
To: Rezaei, Mohammad A. [Tech]
Cc: Richard Warburton; valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>
Subject: Re: Sentinels in collections, was RE: Primitive Queue<any T> considerations

This may work for a set, but doesn't necessarily generalize to any data structure.  Moreover, you're now checking the argument for being one of the two sentinels on all these operations.  There are times when side data or out-of-band data is warranted, but those occasions should be dictated by things other than lack of efficiently expressing a nullable primitive.

On Wed, Nov 18, 2015 at 3:11 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com<mailto:Mohammad.Rezaei at gs.com>> wrote:
Many primitive collections use sentinels *without* requiring removal of those in the collection. This is done by storing a bit of side information. For example, for a set of int, GS Collections uses 0 and 1 as sentinels (meaning empty and removed, respectively). Every call to methods like get/contains/add/etc first checks to see if the value is a sentinel, and if so, queries/updates the side data. For a set, the side data is tiny and trivial: there is a single byte that encode if the set contains 0, 1, both or none.

Thanks
Moh

>-----Original Message-----
>From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net<mailto:valhalla-dev-bounces at openjdk.java.net>] On Behalf Of
>Vitaly Davidovich
>Sent: Wednesday, November 18, 2015 2:31 PM
>To: Richard Warburton
>Cc: valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>
>Subject: Re: Primitive Queue<any T> considerations
>
>Although I agree that sometimes a sentinel or even an entire range of
>values is available to indicate absence, I don't think it's the right
>answer to the question.  In particular, if you're writing a general purpose
>collection, you cannot expect your users to remove one possible value from
>their universe to signal absence.  The collections that do this today are
>simply working around lack of nullable primitives.
>
>On Wed, Nov 18, 2015 at 2:18 PM, Richard Warburton <
>richard.warburton at gmail.com<mailto:richard.warburton at gmail.com>> wrote:
>
>> Hi,
>>
>> I'm not sure about the default null-indicator because every time a queue is
>> > needed in our library, that can serve a source with unique choice of a
>> > default-null value. It is unlikely the users of the library want or can
>> > specify that all the time.
>> >
>>
>> I appreciate that this is diverging directly form your language related
>> question, but it is pertinent to writing anyfied collections using
>> Valhalla. My experience using primitive specialised collections is that it
>> has always been possible to have a sentinel value, though obviously my
>> experience won't necessary reflect that of every single person in the Java
>> community. It isn't always appropriate for it to be 0, which is what I
>> think T.default is currently going to return for primitives and when I've
>> done primitive specialised collections before they allow you to specify the
>> missing value sentinel.
>>
>> Have you got of an actual genuine use case where a sentinel value doesn't
>> work well, rather than a theoretical "hey, maybe you want to have a set
>> that contains every possible int?"
>>
>> regards,
>>
>>   Richard Warburton
>>
>>   http://insightfullogic.com
>>   @RichardWarburto <http://twitter.com/richardwarburto>
>>



From richard.warburton at gmail.com  Wed Nov 18 23:15:16 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Wed, 18 Nov 2015 15:15:16 -0800
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <CAMaYbvLVAxEzFN_e7LktaD263eYLPz5Dj1N7V=xa9stqHnX3Dg@mail.gmail.com>

Hi,

Many primitive collections use sentinels *without* requiring removal of
> those in the collection. This is done by storing a bit of side information.
> For example, for a set of int, GS Collections uses 0 and 1 as sentinels
> (meaning empty and removed, respectively). Every call to methods like
> get/contains/add/etc first checks to see if the value is a sentinel, and if
> so, queries/updates the side data. For a set, the side data is tiny and
> trivial: there is a single byte that encode if the set contains 0, 1, both
> or none.
>

This is entirely correct. Its not that there's a lack of ability to
implement what was being asked for, I was questioning what people's use
cases were around the feature. When I've done primitive collections I've
not added this feature. That's not because I didn't know how to, but
because it simply wasn't required for my use case. In that case why would I
add the complexity and overhead?

My perspective on software is that it should be written to solve problems
that actually exist, rather than problems which are hypothesized. Again - I
don't want to claim that the only use cases that matter are mine, but its
incredibly telling that there were 4 replies to that email, and only 1 of
them actually listed a use case. I'm still not 100% convinced by that but
thanks for providing it. (Of course you don't actually have to convince me
of anything - that's also fine ;) )

regards,

  Richard Warburton

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

From richard.warburton at gmail.com  Wed Nov 18 23:19:15 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Wed, 18 Nov 2015 15:19:15 -0800
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>

Hi,

Agreed, so maybe I misinterpreted Richard?s email (I tried to mitigate by
> changing the subject). Richard, which type of sentinel did you mean?
>

Well I was originally thinking in terms of the Queue interface itself,
which needed a sentinel taken out of the user's domain. I don't think its a
problem to expand the discussion though and you're certainly right to
observe that there are two different kinds of sentinel.

regards,

  Richard Warburton

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

From john.r.rose at oracle.com  Wed Nov 18 23:25:44 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 15:25:44 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
Message-ID: <C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>

On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> A large point of value types
> is they do not touch the heap, and thus do not contribute to any subsequent
> GC pauses.  If I had a large struct, I may be just fine having a slower
> copy operation percolating through the stack.  This is like escape
> analysis, nobody that's avoiding GC is actually relying on it because of
> this "VM's choice" aspect.  I urge you to reconsider this automatic boxing
> aspect.  Nobody is going to complain that the JVM is not automatically
> boxing their large struct, but someone will complain if there's heap
> allocation behind the scenes.

This is an interesting question, especially since early prototyping
of value types may involve a surprising amount of boxing,
particularly for "hard cases" like the large struct you mention.

The above is a good argument to remember, though.
I suppose you mean copies between locals:  Those
should not copy through the heap, in common cases.
A non-small value type will probably need buffering,
but the buffer can be allocated using stack rules,
refcount rules, or the like, so it can be deallocated
in a timely manner without GC interaction.

(BTW, it is possible we will decide that de-opt
transitions will use heap copies, at least at first.)

It seems there are three interesting value type sizes.
Small ones fit in a register or two, and/or can be
atomically loaded and stored by hardware.
Large ones span multiple cache lines, and
have only limited benefit compared to objects.
In the middle, the medium ones require several
instructions to store (and extra work for atomicity)
but still occupy the natural unit of memory, which
is a cache line (or two, relying on prefetch).

> they do not touch the heap


Value types can touch the heap in various use cases,
in the same way that ints can be stored in the heap,
or (new to value types) in that they can contain refs.

It is true that using value types will reduce GC load in
many cases (besides local-to-local copies), but this
is mainly because of their flatness, which reduces
memory pressure and decreases frequency of
dependent loads.

? John

From vitalyd at gmail.com  Wed Nov 18 23:31:37 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 18:31:37 -0500
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
Message-ID: <CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>

I'm still unclear on how we ended up discussing internal sentinels that are
effectively implementation details.  I don't think there's any debate on
this part.

I do, however, disagree on sentinels that leak out of the implementation
and require user to select a magic number.  And I say this as someone who
constantly exploits domain specific constraints on values to optimize
code.  In particular, in a world where optional<value_type> is cheap asking
user to declare a magic number is unfortunate; this is required today, but
it's a language limitation.  I'd hate to have that perpetuated once better
language features are available.

sent from my phone
On Nov 18, 2015 6:19 PM, "Richard Warburton" <richard.warburton at gmail.com>
wrote:

> Hi,
>
> Agreed, so maybe I misinterpreted Richard?s email (I tried to mitigate by
>> changing the subject). Richard, which type of sentinel did you mean?
>>
>
> Well I was originally thinking in terms of the Queue interface itself,
> which needed a sentinel taken out of the user's domain. I don't think its a
> problem to expand the discussion though and you're certainly right to
> observe that there are two different kinds of sentinel.
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>

From john.r.rose at oracle.com  Wed Nov 18 23:41:04 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 15:41:04 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
Message-ID: <DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>

P.S. Meant to respond to this too:

On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> [Brian]
>> Nullability is orthogonal to atomicity.  If he wants nullability, he wraps
>> his values with Optional<T>.  (For refs, Optional<T> will hopefully be the
>> same size as a ref, so it isn't a problem to do this across the board.)
>> For atomicity, you don't switch on size, you just ask for it.  If the
>> values are small, atomicity will be free or cheap anyway.
> 
> 
> Well, if there's going to be a way to request just atomicity (and not
> ordering as well), which will nop if size is atomic natively, then great.

I think value types will be a good way to signal a number of intentions
to the JVM, where today we use special types (WeakReference)
or annotations (@Contended).  An any-parameterized value type
W<T> which wraps another type T will need no header or padding,
and will often have no other storage besides the T value itself.
It will be able to express special storage semantics for the
wrapped T value (expressed as a variable of type W<T> or
an associated VarHandle<T> in some cases).  Special variable
handling conditions could include atomicity, contention, volatility,
dataflow control, finality, optionality, multiplicity, weak rooting, etc., etc.
The fun thing about this is that (potentially) we can mix and match
these features by stacking value types, without sacrificing flatness.

(Somebody is probably thinking, "wait, value types are final, so they
can't make state transitions!"  The answer is that the value as a whole
is mutable.  Remember, "codes like a class, works like an int", and an
int has no mutable subparts by can, as a whole, be mutated, unless
stored in a final variable.)

BTW, what would a weakReference<pair<P,Q>> look like?  Perhaps
it would clear itself only when *both* P and Q went unreachable.
That's a long-standing RFE for weak refs.  It appears that variable
attributes based on value-wrappers may be strictly more expressive,
in some cases, than the present options.

> Otherwise, I'd hate for there to be *any* performance penalty if the size
> is <= word size.

I don't anticipate any such penalty.  Value-based wrappers will be much
slimmer and lighter than object-based wrappers.

?Except for the per-value 64-bit lock word.  ?Kidding.

? John

From vitalyd at gmail.com  Wed Nov 18 23:47:06 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 18:47:06 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
Message-ID: <CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>

John,

By "touching the heap" I was referring to stack allocated value types
getting boxed and roundtripped via the heap, not them being embedded in a
heap object.  I have a ton of use cases where I'd like to do data
encapsulation on-stack and have guarantees that storage is on stack; if JIT
scalarizes across registers, I view that as an optimization.  Most
important is no heap allocation occurs.  If I give the JVM a 1000 byte
struct, I expect it to grow the stack by that amount and copy it; if that
overflows, send me a StackOverflowError, no problem.  Mind you, I (and I'm
sure others) have no plans of 1000 byte structs, but I can easily see some,
not many, that are in the 64-128 byte range.  I'd like this to work just
like if I had written a method accepting 8-16 individual long arguments.

The overarching theme here is I'd like to use the stack a lot more, for
ephemeral/temp storage, and have that guaranteed rather than hope and pray
escape analysis does its thing.  I don't want TLAB or some other thread
local heap segment, I want the stack to be my TLAB :).

Thanks

sent from my phone
On Nov 18, 2015 6:25 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> A large point of value types
> is they do not touch the heap, and thus do not contribute to any subsequent
> GC pauses.  If I had a large struct, I may be just fine having a slower
> copy operation percolating through the stack.  This is like escape
> analysis, nobody that's avoiding GC is actually relying on it because of
> this "VM's choice" aspect.  I urge you to reconsider this automatic boxing
> aspect.  Nobody is going to complain that the JVM is not automatically
> boxing their large struct, but someone will complain if there's heap
> allocation behind the scenes.
>
>
> This is an interesting question, especially since early prototyping
> of value types may involve a surprising amount of boxing,
> particularly for "hard cases" like the large struct you mention.
>
> The above is a good argument to remember, though.
> I suppose you mean copies between locals:  Those
> should not copy through the heap, in common cases.
> A non-small value type will probably need buffering,
> but the buffer can be allocated using stack rules,
> refcount rules, or the like, so it can be deallocated
> in a timely manner without GC interaction.
>
> (BTW, it is possible we will decide that de-opt
> transitions will use heap copies, at least at first.)
>
> It seems there are three interesting value type sizes.
> Small ones fit in a register or two, and/or can be
> atomically loaded and stored by hardware.
> Large ones span multiple cache lines, and
> have only limited benefit compared to objects.
> In the middle, the medium ones require several
> instructions to store (and extra work for atomicity)
> but still occupy the natural unit of memory, which
> is a cache line (or two, relying on prefetch).
>
> they do not touch the heap
>
>
> Value types can touch the heap in various use cases,
> in the same way that ints can be stored in the heap,
> or (new to value types) in that they can contain refs.
>
> It is true that using value types will reduce GC load in
> many cases (besides local-to-local copies), but this
> is mainly because of their flatness, which reduces
> memory pressure and decreases frequency of
> dependent loads.
>
> ? John
>

From john.r.rose at oracle.com  Wed Nov 18 23:51:51 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 15:51:51 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564CE162.2010107@oracle.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
	<CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
	<564CE162.2010107@oracle.com>
Message-ID: <75682841-8AC7-44ED-BE05-96906F888423@oracle.com>

On Nov 18, 2015, at 12:36 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Note that while values are in part about getting flatter data layouts, we do not plan to offer anything in the way of fine-grained layout control, such as allowing for explicit alignment requirements.  (Though other efforts, such as Project Panama, may have something to offer here).

Right; it's easier on the JVM to let it have its own choice on layouts.

For example, HotSpot usually repacks object fields so that refs
are all together, longs/doubles all together, ints/floats together,
etc., to minimize fragmentation and certain GC overheads.
Value types are likely to play such games also.

Open question:  How valuable would it be to "export" JVM-laid-out
values off heap?  My take:  Not a killer feature if done via bitwise
copies, since off-heap storage often needs an externally defined
layout.  But, perhaps we could define a mapping (or several
mappings) from value types to native types, and build copy
operations into Panama.  Simple types like complex<double>
should copy bitwise between heaps, even other types like
tuple<long, boolean, long> do not.  The main point is that
Panama expects to take data schemas from multiple
sources (not just C/C++), and that will play well with
value types.

? John

From vitalyd at gmail.com  Wed Nov 18 23:57:51 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 18:57:51 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <75682841-8AC7-44ED-BE05-96906F888423@oracle.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
	<CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
	<564CE162.2010107@oracle.com>
	<75682841-8AC7-44ED-BE05-96906F888423@oracle.com>
Message-ID: <CAHjP37H54BoSphfc_3tT=1RmJPeRK9tHQnbfP_14nM-jEjc2Rw@mail.gmail.com>

Personally, I'd love to see layout and alignment exposed.  I'd also like to
see something like this Slice:
https://github.com/joeduffy/slice.net/blob/master/README.md.  Being able to
overlay a typesafe and cheap struct on top of a byte buffer would save some
boilerplate coding.

sent from my phone
On Nov 18, 2015 6:52 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 12:36 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> Note that while values are in part about getting flatter data layouts, we
> do not plan to offer anything in the way of fine-grained layout control,
> such as allowing for explicit alignment requirements.  (Though other
> efforts, such as Project Panama, may have something to offer here).
>
>
> Right; it's easier on the JVM to let it have its own choice on layouts.
>
> For example, HotSpot usually repacks object fields so that refs
> are all together, longs/doubles all together, ints/floats together,
> etc., to minimize fragmentation and certain GC overheads.
> Value types are likely to play such games also.
>
> Open question:  How valuable would it be to "export" JVM-laid-out
> values off heap?  My take:  Not a killer feature if done via bitwise
> copies, since off-heap storage often needs an externally defined
> layout.  But, perhaps we could define a mapping (or several
> mappings) from value types to native types, and build copy
> operations into Panama.  Simple types like complex<double>
> should copy bitwise between heaps, even other types like
> tuple<long, boolean, long> do not.  The main point is that
> Panama expects to take data schemas from multiple
> sources (not just C/C++), and that will play well with
> value types.
>
> ? John
>

From vitalyd at gmail.com  Thu Nov 19 00:01:30 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 19:01:30 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>
Message-ID: <CAHjP37HC-mk1aeqPOjqH8-VPgFmN9+jAek5Yxci8kd7XY-XjQQ@mail.gmail.com>

Right, by performance penalty I meant that I'd like to ask only for
atomicity and not also ordering.  If the T is <= machine word, I'd like it
to act just like if I hadn't requested atomicity.  In other words, I don't
want fences here for ordering.

sent from my phone
On Nov 18, 2015 6:41 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> P.S. Meant to respond to this too:
>
> On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> [Brian]
>
> Nullability is orthogonal to atomicity.  If he wants nullability, he wraps
>
> his values with Optional<T>.  (For refs, Optional<T> will hopefully be the
> same size as a ref, so it isn't a problem to do this across the board.)
> For atomicity, you don't switch on size, you just ask for it.  If the
> values are small, atomicity will be free or cheap anyway.
>
>
>
> Well, if there's going to be a way to request just atomicity (and not
> ordering as well), which will nop if size is atomic natively, then great.
>
>
> I think value types will be a good way to signal a number of intentions
> to the JVM, where today we use special types (WeakReference)
> or annotations (@Contended).  An any-parameterized value type
> W<T> which wraps another type T will need no header or padding,
> and will often have no other storage besides the T value itself.
> It will be able to express special storage semantics for the
> wrapped T value (expressed as a variable of type W<T> or
> an associated VarHandle<T> in some cases).  Special variable
> handling conditions could include atomicity, contention, volatility,
> dataflow control, finality, optionality, multiplicity, weak rooting, etc.,
> etc.
> The fun thing about this is that (potentially) we can mix and match
> these features by stacking value types, without sacrificing flatness.
>
> (Somebody is probably thinking, "wait, value types are final, so they
> can't make state transitions!"  The answer is that the value as a whole
> is mutable.  Remember, "codes like a class, works like an int", and an
> int has no mutable subparts by can, as a whole, be mutated, unless
> stored in a final variable.)
>
> BTW, what would a weakReference<pair<P,Q>> look like?  Perhaps
> it would clear itself only when *both* P and Q went unreachable.
> That's a long-standing RFE for weak refs.  It appears that variable
> attributes based on value-wrappers may be strictly more expressive,
> in some cases, than the present options.
>
> Otherwise, I'd hate for there to be *any* performance penalty if the size
> is <= word size.
>
>
> I don't anticipate any such penalty.  Value-based wrappers will be much
> slimmer and lighter than object-based wrappers.
>
> ?Except for the per-value 64-bit lock word.  ?Kidding.
>
> ? John
>

From john.r.rose at oracle.com  Thu Nov 19 00:20:21 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 16:20:21 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
Message-ID: <72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>

On Nov 18, 2015, at 3:47 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> By "touching the heap" I was referring to stack allocated value types getting boxed and roundtripped via the heap, not them being embedded in a heap object.

Right; you are saying that copies through stack and local slots should
not increase GC load.

> I have a ton of use cases where I'd like to do data encapsulation on-stack and have guarantees that storage is on stack; if JIT scalarizes across registers, I view that as an optimization.

In terms of the S/M/L size distinction:  That optimization will happen
mostly for "small" values, not so much for "medium", and not for "large".

> Most important is no heap allocation occurs.  If I give the JVM a 1000 byte struct, I expect it to grow the stack by that amount and copy it; if that overflows, send me a StackOverflowError, no problem.

Just to be clear:  We are not designing the value type system to support
1000 byte structs.  If we get good enough results, those guys will benefit,
but IMO it won't be a showstopper if 1000 byte structs are kind of slow
when stored in values.  The deep reason for this is that a 1-word or
10-word value is much flatter than the corresponding object, but a
1000 byte value is slightly flatter (1-6%) than the corresponding object.
By that I mean the memory overhead due to the 12-byte header,
and the cache traffic overhead due to having to do an extra load
to get the pointer, are incrementally small compared to the 1000 bytes.

> Mind you, I (and I'm sure others) have no plans of 1000 byte structs,
(Thank you!)

> but I can easily see some, not many, that are in the 64-128 byte range.  I'd like this to work just like if I had written a method accepting 8-16 individual long arguments.
I agree.  Those are the "medium" size range.  To make another
useful distinction:  Medium values might be "buffered" via an
indirection somewhere (probably thread-local), but will not usually
be "boxed" on the heap where the GC would have to delete them.
> The overarching theme here is I'd like to use the stack a lot more, for ephemeral/temp storage, and have that guaranteed rather than hope and pray escape analysis does its thing.  I don't want TLAB or some other thread local heap segment, I want the stack to be my TLAB :).
> 
I agree with this theme, but watch out:  If you want *mutable* ephemeral
storage, and if you want to write *methods* which manipulate parts of
this storage inside an abstraction, you will need at a small GC-able
object per abstraction instance, even if most of the state is "auto"
storage class. 

And, you will need something new, the ability to refer to the storage
block (on stack) safely from methods.  Fortunately, we are building
such things (see discussions on the stack walk API, which reads
pointers into the thread, or java.nicl.Scope in Panama which will
wrap "auto" storage class variables).

This desire to have mutable on-stack abstractions is sharply at odds
with the desire to have sharable, immutable on-heap abstractions.
It is the root (or one of the roots) of the long-running argument about
whether value fields should be mutable.  The only simple, tractable
answer is "no", which means we need to find workarounds for
folks that want on-stack iterators, etc.

? John

From john.r.rose at oracle.com  Thu Nov 19 00:23:00 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 16:23:00 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37H54BoSphfc_3tT=1RmJPeRK9tHQnbfP_14nM-jEjc2Rw@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
	<CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
	<564CE162.2010107@oracle.com>
	<75682841-8AC7-44ED-BE05-96906F888423@oracle.com>
	<CAHjP37H54BoSphfc_3tT=1RmJPeRK9tHQnbfP_14nM-jEjc2Rw@mail.gmail.com>
Message-ID: <6A03C32E-0731-4C72-85D1-F5729FC17781@oracle.com>

On Nov 18, 2015, at 3:57 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> Personally, I'd love to see layout and alignment exposed.  I'd also like to see something like this Slice: https://github.com/joeduffy/slice.net/blob/master/README.md <https://github.com/joeduffy/slice.net/blob/master/README.md>.  Being able to overlay a typesafe and cheap struct on top of a byte buffer would save some boilerplate coding.

Yes.  That idea doesn't fall out naturally from value types, but it does
fall out from VarHandles (maybe plus values), and is also important
in Panama, where it appears as secured references and pointers.


From john.r.rose at oracle.com  Thu Nov 19 00:26:58 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 16:26:58 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37HC-mk1aeqPOjqH8-VPgFmN9+jAek5Yxci8kd7XY-XjQQ@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>
	<CAHjP37HC-mk1aeqPOjqH8-VPgFmN9+jAek5Yxci8kd7XY-XjQQ@mail.gmail.com>
Message-ID: <A03B1FE8-60AC-482F-B79C-95A3D170C5EE@oracle.com>

On Nov 18, 2015, at 4:01 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> Right, by performance penalty I meant that I'd like to ask only for atomicity and not also ordering.  If the T is <= machine word, I'd like it to act just like if I hadn't requested atomicity.  In other words, I don't want fences here for ordering.

OK, check that.  So an atomic T is not the same as a Java-volatile T.
This is a reason *not* to reuse the "volatile" keyword for def-site atomicity,
and to consider a new keyword for use-site atomicity.

We won't provide keywords for all use cases, since wrappers are
expressive enough to fill the gaps (as in C++).  The most important
new expressive point (IMO) is opt-in, def-site, anti-tearing; that merits
something like a keyword, since it has security implications.

From vitalyd at gmail.com  Thu Nov 19 00:35:00 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 19:35:00 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
	<72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
Message-ID: <CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>

Why do medium sized structs require "buffering" and indirection? Do you
mean they're stored on the stack instead of scalarized in registers? If so,
sure, no problem.

As for the 1000 byte struct, I don't care if "moving" it via heap is
faster, I don't want GC pressure :).  If I do this dance enough times and a
GC comes along, I may lose any gains and then some that I had via faster
movement/access earlier.

As for mutable stack storage (e.g. iterators perfect example), I think it's
very important to have some story here.  I've long been advocating for
allowing mutable structs, but you'd need to allow passing them by reference
as well then.  CLR does this, so it's not some new ground entirely.
However, I'd be happy with whatever other mechanics as long as the use case
is met.

Thanks

sent from my phone
On Nov 18, 2015 7:20 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 3:47 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> By "touching the heap" I was referring to stack allocated value types
> getting boxed and roundtripped via the heap, not them being embedded in a
> heap object.
>
>
> Right; you are saying that copies through stack and local slots should
> not increase GC load.
>
> I have a ton of use cases where I'd like to do data encapsulation on-stack
> and have guarantees that storage is on stack; if JIT scalarizes across
> registers, I view that as an optimization.
>
>
> In terms of the S/M/L size distinction:  That optimization will happen
> mostly for "small" values, not so much for "medium", and not for "large".
>
> Most important is no heap allocation occurs.  If I give the JVM a 1000
> byte struct, I expect it to grow the stack by that amount and copy it; if
> that overflows, send me a StackOverflowError, no problem.
>
>
> Just to be clear:  We are not designing the value type system to support
> 1000 byte structs.  If we get good enough results, those guys will benefit,
> but IMO it won't be a showstopper if 1000 byte structs are kind of slow
> when stored in values.  The deep reason for this is that a 1-word or
> 10-word value is much flatter than the corresponding object, but a
> 1000 byte value is slightly flatter (1-6%) than the corresponding object.
> By that I mean the memory overhead due to the 12-byte header,
> and the cache traffic overhead due to having to do an extra load
> to get the pointer, are incrementally small compared to the 1000 bytes.
>
> Mind you, I (and I'm sure others) have no plans of 1000 byte structs,
>
> (Thank you!)
>
> but I can easily see some, not many, that are in the 64-128 byte range.
> I'd like this to work just like if I had written a method accepting 8-16
> individual long arguments.
>
> I agree.  Those are the "medium" size range.  To make another
> useful distinction:  Medium values might be "buffered" via an
> indirection somewhere (probably thread-local), but will not usually
> be "boxed" on the heap where the GC would have to delete them.
>
> The overarching theme here is I'd like to use the stack a lot more, for
> ephemeral/temp storage, and have that guaranteed rather than hope and pray
> escape analysis does its thing.  I don't want TLAB or some other thread
> local heap segment, I want the stack to be my TLAB :).
>
> I agree with this theme, but watch out:  If you want *mutable* ephemeral
> storage, and if you want to write *methods* which manipulate parts of
> this storage inside an abstraction, you will need at a small GC-able
> object per abstraction instance, even if most of the state is "auto"
> storage class.
>
> And, you will need something new, the ability to refer to the storage
> block (on stack) safely from methods.  Fortunately, we are building
> such things (see discussions on the stack walk API, which reads
> pointers into the thread, or java.nicl.Scope in Panama which will
> wrap "auto" storage class variables).
>
> This desire to have mutable on-stack abstractions is sharply at odds
> with the desire to have sharable, immutable on-heap abstractions.
> It is the root (or one of the roots) of the long-running argument about
> whether value fields should be mutable.  The only simple, tractable
> answer is "no", which means we need to find workarounds for
> folks that want on-stack iterators, etc.
>
> ? John
>

From vitalyd at gmail.com  Thu Nov 19 00:35:42 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 19:35:42 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <A03B1FE8-60AC-482F-B79C-95A3D170C5EE@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>
	<CAHjP37HC-mk1aeqPOjqH8-VPgFmN9+jAek5Yxci8kd7XY-XjQQ@mail.gmail.com>
	<A03B1FE8-60AC-482F-B79C-95A3D170C5EE@oracle.com>
Message-ID: <CAHjP37HuqLKwhT3Ar0t4ic0T9objE2T9X_RLyJpc+A4Fquz1VQ@mail.gmail.com>

Excellent, happy to hear that.

sent from my phone
On Nov 18, 2015 7:27 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 4:01 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> > Right, by performance penalty I meant that I'd like to ask only for
> atomicity and not also ordering.  If the T is <= machine word, I'd like it
> to act just like if I hadn't requested atomicity.  In other words, I don't
> want fences here for ordering.
>
> OK, check that.  So an atomic T is not the same as a Java-volatile T.
> This is a reason *not* to reuse the "volatile" keyword for def-site
> atomicity,
> and to consider a new keyword for use-site atomicity.
>
> We won't provide keywords for all use cases, since wrappers are
> expressive enough to fill the gaps (as in C++).  The most important
> new expressive point (IMO) is opt-in, def-site, anti-tearing; that merits
> something like a keyword, since it has security implications.

From john.r.rose at oracle.com  Thu Nov 19 00:35:43 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 16:35:43 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
Message-ID: <E8EF30B1-F83A-4A0B-8780-B816A04983EC@oracle.com>

On Nov 18, 2015, at 12:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Using David's example, say he wanted to have queue of nullable longs, which
> internally he'd store as Optional<long>.  But how does he specify in his
> generic class definition that when sizeof (Optional<T>) > word size that
> he'd like atomic access? This goes back to specialization selection, but
> has size constraint.

It doesn't need specialization.  It can be expressed with a use-site keyword
for atomicity, or (better) just for a suitable wrapper type.

class MyQ<T> {
   private optional<T>[] buf0;
   private atomic<T>[] buf1;
   private atomic<optional<T>>[] buf2;
   ...
}

An atomic<T> of a naturally atomic type T can be bitwise identical
to its underlying T.  For a larger T, the JVM will have to allocate
mutex resources, but it is not required to allocate a mutex per field,
so it is likely the resources will be amortizable (e.g., in the containing
object header, split lock side table, etc., etc.).


From vitalyd at gmail.com  Thu Nov 19 00:39:57 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 19:39:57 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <E8EF30B1-F83A-4A0B-8780-B816A04983EC@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<E8EF30B1-F83A-4A0B-8780-B816A04983EC@oracle.com>
Message-ID: <CAHjP37F+eeGmasoHX6ABWLaRw_LxxiHMcCSVAWX-+W7JjB1BYA@mail.gmail.com>

Yes, this is a good approach.

sent from my phone
On Nov 18, 2015 7:35 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 12:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> Using David's example, say he wanted to have queue of nullable longs, which
> internally he'd store as Optional<long>.  But how does he specify in his
> generic class definition that when sizeof (Optional<T>) > word size that
> he'd like atomic access? This goes back to specialization selection, but
> has size constraint.
>
>
> It doesn't need specialization.  It can be expressed with a use-site
> keyword
> for atomicity, or (better) just for a suitable wrapper type.
>
> class MyQ<T> {
>    private optional<T>[] buf0;
>    private atomic<T>[] buf1;
>    private atomic<optional<T>>[] buf2;
>    ...
> }
>
> An atomic<T> of a naturally atomic type T can be bitwise identical
> to its underlying T.  For a larger T, the JVM will have to allocate
> mutex resources, but it is not required to allocate a mutex per field,
> so it is likely the resources will be amortizable (e.g., in the containing
> object header, split lock side table, etc., etc.).
>
>

From john.r.rose at oracle.com  Thu Nov 19 00:46:57 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 16:46:57 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
	<72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
	<CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
Message-ID: <EA8D2B7D-E1ED-4FBC-B838-0E8FE774F414@oracle.com>

On Nov 18, 2015, at 4:35 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> Why do medium sized structs require "buffering" and indirection? Do you mean they're stored on the stack instead of scalarized in registers? If so, sure, no problem.

Check.
> As for the 1000 byte struct, I don't care if "moving" it via heap is faster, I don't want GC pressure :).  If I do this dance enough times and a GC comes along, I may lose any gains and then some that I had via faster movement/access earlier.
> 
This will require some investigation when we get prototypes.
I'm not saying it's impossible, but promising "no GC pressure"
for "1000 byte structs" is low on my priority list.  (But I've got
a few ideas to try when the time comes?)
> As for mutable stack storage (e.g. iterators perfect example), I think it's very important to have some story here.  I've long been advocating for allowing mutable structs, but you'd need to allow passing them by reference as well then.  CLR does this, so it's not some new ground entirely.
> 
> However, I'd be happy with whatever other mechanics as long as the use case is met.
> 

Again, this will require extra work.  It's almost as if we want
a new feature here: Confined objects, which are mutable
and guaranteed to stay thread-local.  (Java has finality
but not confinement; as Brian has written, both are
important concurrency tools.)

The CLR example is not one I want to follow.  I think
their attempt to support both kinds of value types
(mutable, immutable) caused them some problems
we need to avoid.  First, atomicity is not central in
the story.  Also, value aliasing is intermittent and hard
to follow in the code, so that there are puzzlers where
value field writes are invisibly lost, when the value
is a temp.

? John

From vitalyd at gmail.com  Thu Nov 19 00:49:39 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 19:49:39 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
	<72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
	<CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
Message-ID: <CAHjP37Ew5rpDeUz8kzBi2Fm27LGCDgFPpP5yDwThVyX8aoTDGg@mail.gmail.com>

By the way, thinking about this 1000 byte struct case, it may occur with
network protocol type of work.  One may want to represent a message as some
number of type safe structs embedded in an envelope struct, with total size
near there.

sent from my phone
On Nov 18, 2015 7:35 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Why do medium sized structs require "buffering" and indirection? Do you
> mean they're stored on the stack instead of scalarized in registers? If so,
> sure, no problem.
>
> As for the 1000 byte struct, I don't care if "moving" it via heap is
> faster, I don't want GC pressure :).  If I do this dance enough times and a
> GC comes along, I may lose any gains and then some that I had via faster
> movement/access earlier.
>
> As for mutable stack storage (e.g. iterators perfect example), I think
> it's very important to have some story here.  I've long been advocating for
> allowing mutable structs, but you'd need to allow passing them by reference
> as well then.  CLR does this, so it's not some new ground entirely.
> However, I'd be happy with whatever other mechanics as long as the use case
> is met.
>
> Thanks
>
> sent from my phone
> On Nov 18, 2015 7:20 PM, "John Rose" <john.r.rose at oracle.com> wrote:
>
>> On Nov 18, 2015, at 3:47 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>> By "touching the heap" I was referring to stack allocated value types
>> getting boxed and roundtripped via the heap, not them being embedded in a
>> heap object.
>>
>>
>> Right; you are saying that copies through stack and local slots should
>> not increase GC load.
>>
>> I have a ton of use cases where I'd like to do data encapsulation
>> on-stack and have guarantees that storage is on stack; if JIT scalarizes
>> across registers, I view that as an optimization.
>>
>>
>> In terms of the S/M/L size distinction:  That optimization will happen
>> mostly for "small" values, not so much for "medium", and not for "large".
>>
>> Most important is no heap allocation occurs.  If I give the JVM a 1000
>> byte struct, I expect it to grow the stack by that amount and copy it; if
>> that overflows, send me a StackOverflowError, no problem.
>>
>>
>> Just to be clear:  We are not designing the value type system to support
>> 1000 byte structs.  If we get good enough results, those guys will
>> benefit,
>> but IMO it won't be a showstopper if 1000 byte structs are kind of slow
>> when stored in values.  The deep reason for this is that a 1-word or
>> 10-word value is much flatter than the corresponding object, but a
>> 1000 byte value is slightly flatter (1-6%) than the corresponding object.
>> By that I mean the memory overhead due to the 12-byte header,
>> and the cache traffic overhead due to having to do an extra load
>> to get the pointer, are incrementally small compared to the 1000 bytes.
>>
>> Mind you, I (and I'm sure others) have no plans of 1000 byte structs,
>>
>> (Thank you!)
>>
>> but I can easily see some, not many, that are in the 64-128 byte range.
>> I'd like this to work just like if I had written a method accepting 8-16
>> individual long arguments.
>>
>> I agree.  Those are the "medium" size range.  To make another
>> useful distinction:  Medium values might be "buffered" via an
>> indirection somewhere (probably thread-local), but will not usually
>> be "boxed" on the heap where the GC would have to delete them.
>>
>> The overarching theme here is I'd like to use the stack a lot more, for
>> ephemeral/temp storage, and have that guaranteed rather than hope and pray
>> escape analysis does its thing.  I don't want TLAB or some other thread
>> local heap segment, I want the stack to be my TLAB :).
>>
>> I agree with this theme, but watch out:  If you want *mutable* ephemeral
>> storage, and if you want to write *methods* which manipulate parts of
>> this storage inside an abstraction, you will need at a small GC-able
>> object per abstraction instance, even if most of the state is "auto"
>> storage class.
>>
>> And, you will need something new, the ability to refer to the storage
>> block (on stack) safely from methods.  Fortunately, we are building
>> such things (see discussions on the stack walk API, which reads
>> pointers into the thread, or java.nicl.Scope in Panama which will
>> wrap "auto" storage class variables).
>>
>> This desire to have mutable on-stack abstractions is sharply at odds
>> with the desire to have sharable, immutable on-heap abstractions.
>> It is the root (or one of the roots) of the long-running argument about
>> whether value fields should be mutable.  The only simple, tractable
>> answer is "no", which means we need to find workarounds for
>> folks that want on-stack iterators, etc.
>>
>> ? John
>>
>

From Mohammad.Rezaei at gs.com  Thu Nov 19 01:15:26 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Wed, 18 Nov 2015 20:15:26 -0500
Subject: Sentinels in collections, was RE: Primitive Queue<any T>
	considerations
In-Reply-To: <CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>

Richard asked for examples of collections that had to have sentinels and I provided some, but realizing that these are internal ones, changed the subject.

From a Valhalla perspective, the fact that one cannot manufacture a sentinel besides T.default is a real problem for collections that need more than one sentinel. The current types (primitives, references) don?t have this limitation. (This is also not a problem in languages like C where I can cast a struct to char* and fill it with arbitrary bit patterns).

Thanks
Moh

From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Wednesday, November 18, 2015 6:32 PM
To: Richard Warburton
Cc: valhalla-dev at openjdk.java.net; Rezaei, Mohammad A. [Tech]
Subject: Re: Sentinels in collections, was RE: Primitive Queue<any T> considerations


I'm still unclear on how we ended up discussing internal sentinels that are effectively implementation details.  I don't think there's any debate on this part.

I do, however, disagree on sentinels that leak out of the implementation and require user to select a magic number.  And I say this as someone who constantly exploits domain specific constraints on values to optimize code.  In particular, in a world where optional<value_type> is cheap asking user to declare a magic number is unfortunate; this is required today, but it's a language limitation.  I'd hate to have that perpetuated once better language features are available.

sent from my phone
On Nov 18, 2015 6:19 PM, "Richard Warburton" <richard.warburton at gmail.com<mailto:richard.warburton at gmail.com>> wrote:
Hi,

Agreed, so maybe I misinterpreted Richard?s email (I tried to mitigate by changing the subject). Richard, which type of sentinel did you mean?

Well I was originally thinking in terms of the Queue interface itself, which needed a sentinel taken out of the user's domain. I don't think its a problem to expand the discussion though and you're certainly right to observe that there are two different kinds of sentinel.

regards,
  Richard Warburton
  http://insightfullogic.com
  @RichardWarburto<http://twitter.com/richardwarburto>

From john.r.rose at oracle.com  Thu Nov 19 01:18:45 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 17:18:45 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
Message-ID: <796F862E-7CE2-4B2A-B487-CC8E79990C58@oracle.com>

On Nov 18, 2015, at 11:15 AM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
> 
> That?s a good question. How would arbitrary-sized values be assigned into an array without any other thread observing the value halfway between two states with its invariants not holding? 

Yes, it is a very good question.  The basic tools are buffering (pointer-swapping),
locking (e.g., seq-locks, maybe split along array chunks), freezing (safe publication),
and thread confinement (including existing object synch infra).  Plus whatever
acceleration the hardware can give for simple transactions (TSX, HLE).
Plus working carefully with user expectations, as we do today with the
related issue of object tearing (ArrayList might tear, String won't).

It will require experimentation to find the best combination of these measures.

I have to give props to Jeroen Fritjers on this; when I described the 2012 version of
values to him he immediately zeroed in on the problem of array element atomicity.

? John

P.S. FTR, some background info on tearing (not array-specific) is here:
  https://blogs.oracle.com/jrose/entry/value_types_and_struct_tearing <https://blogs.oracle.com/jrose/entry/value_types_and_struct_tearing>



From vitalyd at gmail.com  Thu Nov 19 02:12:32 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 21:12:32 -0500
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <CAHjP37Eh8_5YhzQh4BVQPSnyb0taOB41NghFQgm6o_eN+wfM_g@mail.gmail.com>

How do you imagine multiple sentinels would/could work in a generic
collection? Specialization for some known types? How would user defined
value types fit there?

sent from my phone
On Nov 18, 2015 8:15 PM, "Rezaei, Mohammad A." <Mohammad.Rezaei at gs.com>
wrote:

> Richard asked for examples of collections that had to have sentinels and I
> provided some, but realizing that these are internal ones, changed the
> subject.
>
>
>
> From a Valhalla perspective, the fact that one cannot manufacture a
> sentinel besides T.default is a real problem for collections that need more
> than one sentinel. The current types (primitives, references) don?t have
> this limitation. (This is also not a problem in languages like C where I
> can cast a struct to char* and fill it with arbitrary bit patterns).
>
>
>
> Thanks
>
> Moh
>
>
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Wednesday, November 18, 2015 6:32 PM
> *To:* Richard Warburton
> *Cc:* valhalla-dev at openjdk.java.net; Rezaei, Mohammad A. [Tech]
> *Subject:* Re: Sentinels in collections, was RE: Primitive Queue<any T>
> considerations
>
>
>
> I'm still unclear on how we ended up discussing internal sentinels that
> are effectively implementation details.  I don't think there's any debate
> on this part.
>
> I do, however, disagree on sentinels that leak out of the implementation
> and require user to select a magic number.  And I say this as someone who
> constantly exploits domain specific constraints on values to optimize
> code.  In particular, in a world where optional<value_type> is cheap asking
> user to declare a magic number is unfortunate; this is required today, but
> it's a language limitation.  I'd hate to have that perpetuated once better
> language features are available.
>
> sent from my phone
>
> On Nov 18, 2015 6:19 PM, "Richard Warburton" <richard.warburton at gmail.com>
> wrote:
>
> Hi,
>
>
>
> Agreed, so maybe I misinterpreted Richard?s email (I tried to mitigate by
> changing the subject). Richard, which type of sentinel did you mean?
>
>
>
> Well I was originally thinking in terms of the Queue interface itself,
> which needed a sentinel taken out of the user's domain. I don't think its a
> problem to expand the discussion though and you're certainly right to
> observe that there are two different kinds of sentinel.
>
>
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>
>   @RichardWarburto <http://twitter.com/richardwarburto>
>

From vitalyd at gmail.com  Thu Nov 19 02:18:59 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 21:18:59 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <EA8D2B7D-E1ED-4FBC-B838-0E8FE774F414@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
	<72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
	<CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
	<EA8D2B7D-E1ED-4FBC-B838-0E8FE774F414@oracle.com>
Message-ID: <CAHjP37GZ97Tph5893MVV4U9bSG0vS9KBXDesanOQmKF8RUneVw@mail.gmail.com>

I'd be open to a new feature as well.  Really, I'd like the facility there
with the requisite performance aspects, I'm not married to any particular
mechanics.

Aliasing of mutable value types is an overblown concern, IME.  I've used
them quite a bit in C# and didn't find any puzzlers.  Does one need to be
careful? Sure, but I find myself being more careful in java when trying to
avoid heap allocations and indirection (i.e. copious primitive abuse, byte
buf manual layouts, etc).

Also, you can have "lost" writes even with immutable types, e.g.:

MyMutableInt x = new ...
x.add(...); oops forgot to assign to new local

sent from my phone
On Nov 18, 2015 7:47 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 4:35 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> Why do medium sized structs require "buffering" and indirection? Do you
> mean they're stored on the stack instead of scalarized in registers? If so,
> sure, no problem.
>
>
> Check.
>
> As for the 1000 byte struct, I don't care if "moving" it via heap is
> faster, I don't want GC pressure :).  If I do this dance enough times and a
> GC comes along, I may lose any gains and then some that I had via faster
> movement/access earlier.
>
> This will require some investigation when we get prototypes.
> I'm not saying it's impossible, but promising "no GC pressure"
> for "1000 byte structs" is low on my priority list.  (But I've got
> a few ideas to try when the time comes?)
>
> As for mutable stack storage (e.g. iterators perfect example), I think
> it's very important to have some story here.  I've long been advocating for
> allowing mutable structs, but you'd need to allow passing them by reference
> as well then.  CLR does this, so it's not some new ground entirely.
>
> However, I'd be happy with whatever other mechanics as long as the use
> case is met.
>
> Again, this will require extra work.  It's almost as if we want
> a new feature here: Confined objects, which are mutable
> and guaranteed to stay thread-local.  (Java has finality
> but not confinement; as Brian has written, both are
> important concurrency tools.)
>
> The CLR example is not one I want to follow.  I think
> their attempt to support both kinds of value types
> (mutable, immutable) caused them some problems
> we need to avoid.  First, atomicity is not central in
> the story.  Also, value aliasing is intermittent and hard
> to follow in the code, so that there are puzzlers where
> value field writes are invisibly lost, when the value
> is a temp.
>
> ? John
>

From Mohammad.Rezaei at gs.com  Thu Nov 19 02:57:45 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Wed, 18 Nov 2015 21:57:45 -0500
Subject: Sentinels in collections, was RE: Primitive Queue<any T>
	considerations
In-Reply-To: <CAHjP37Eh8_5YhzQh4BVQPSnyb0taOB41NghFQgm6o_eN+wfM_g@mail.gmail.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Eh8_5YhzQh4BVQPSnyb0taOB41NghFQgm6o_eN+wfM_g@mail.gmail.com>
Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E19A@GSCMAMP06EX.firmwide.corp.gs.com>

The simple answer is, I don?t know, or rather, I have a few really bad ideas. I know what I would do in C, but that?s the realm of headerless-structs, not immutable-value-types.

Here is my current list of bad ideas:


1)      For pure value types (no references), it?s safe to fill the bits with arbitrary values, so long as that doesn?t leak outside the collection. Let me construct any pure user defined value type with a single byte (I don?t think I need more than 256 sentinels), fill the rest with zero. This can be extended to value types that have at least 1 byte of primitive storage, but doesn?t work for value types that are just references.

a.       Additionally, let me store these not as class members, but per-reified-type-static members.

2)      Some sort of union type. I think this can be formalized better than (1), but I?m not sure all safety can be guaranteed without overhead. It inherently also requires a subject that I haven?t seen discussed: casting and maybe its uglier cousin, coercion. Primitives have both and that?ll be an interesting story for user defined value types.

3)      Give up and use one of the following:

a.       Flat, but fat: define my own value type that?s a byte+V. Decent cache line behavior, but significant memory overhead and alignment concerns.

b.      Flat, reasonably slim, but painful: define my own value type that?s a byte + 4 values (to get up to 4 sentinels, 2 bits per value). Address calculation is a pain, but addressing the individual values is an exercise in patience (and 4x code bloat).

c.       Unflat, fast-ish: keep a separate bit set (with as many bits per value as I need sentinel types).

d.      Unflat, compact: since most of the time the special sentinels (e.g. REMOVED) are sparse, use a sparse side structure instead of a bitset. I think this will be quite slow and the sparseness assumption better be right, or it?ll also be bigger than a bitset.

I?ve been shaking my head as I wrote this down and I?m questioning my sanity for mailing this out, but there you have it.

Thanks
Moh

From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Wednesday, November 18, 2015 9:13 PM
To: Rezaei, Mohammad A. [Tech]
Cc: valhalla-dev at openjdk.java.net; Richard Warburton
Subject: RE: Sentinels in collections, was RE: Primitive Queue<any T> considerations


How do you imagine multiple sentinels would/could work in a generic collection? Specialization for some known types? How would user defined value types fit there?

sent from my phone
On Nov 18, 2015 8:15 PM, "Rezaei, Mohammad A." <Mohammad.Rezaei at gs.com<mailto:Mohammad.Rezaei at gs.com>> wrote:
Richard asked for examples of collections that had to have sentinels and I provided some, but realizing that these are internal ones, changed the subject.

From a Valhalla perspective, the fact that one cannot manufacture a sentinel besides T.default is a real problem for collections that need more than one sentinel. The current types (primitives, references) don?t have this limitation. (This is also not a problem in languages like C where I can cast a struct to char* and fill it with arbitrary bit patterns).

Thanks
Moh

From: Vitaly Davidovich [mailto:vitalyd at gmail.com<mailto:vitalyd at gmail.com>]
Sent: Wednesday, November 18, 2015 6:32 PM
To: Richard Warburton
Cc: valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>; Rezaei, Mohammad A. [Tech]
Subject: Re: Sentinels in collections, was RE: Primitive Queue<any T> considerations


I'm still unclear on how we ended up discussing internal sentinels that are effectively implementation details.  I don't think there's any debate on this part.

I do, however, disagree on sentinels that leak out of the implementation and require user to select a magic number.  And I say this as someone who constantly exploits domain specific constraints on values to optimize code.  In particular, in a world where optional<value_type> is cheap asking user to declare a magic number is unfortunate; this is required today, but it's a language limitation.  I'd hate to have that perpetuated once better language features are available.

sent from my phone
On Nov 18, 2015 6:19 PM, "Richard Warburton" <richard.warburton at gmail.com<mailto:richard.warburton at gmail.com>> wrote:
Hi,

Agreed, so maybe I misinterpreted Richard?s email (I tried to mitigate by changing the subject). Richard, which type of sentinel did you mean?

Well I was originally thinking in terms of the Queue interface itself, which needed a sentinel taken out of the user's domain. I don't think its a problem to expand the discussion though and you're certainly right to observe that there are two different kinds of sentinel.

regards,
  Richard Warburton
  http://insightfullogic.com
  @RichardWarburto<http://twitter.com/richardwarburto>

From richard.warburton at gmail.com  Thu Nov 19 03:27:28 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Wed, 18 Nov 2015 19:27:28 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37H54BoSphfc_3tT=1RmJPeRK9tHQnbfP_14nM-jEjc2Rw@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
	<CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
	<564CE162.2010107@oracle.com>
	<75682841-8AC7-44ED-BE05-96906F888423@oracle.com>
	<CAHjP37H54BoSphfc_3tT=1RmJPeRK9tHQnbfP_14nM-jEjc2Rw@mail.gmail.com>
Message-ID: <CAMaYbvJ3EadsHVCPbNfZSmyd3M2ErQ48jP5xi-eYLVDbu_2RLA@mail.gmail.com>

Hi,

Vitaly: so would I but are you sure that that use case should be part of
Valhalla? It seems highly orthogonal to value types. The only thing they
have in common is a different memory layout from Java objects.
On 18 Nov 2015 15:58, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Personally, I'd love to see layout and alignment exposed.  I'd also like to
> see something like this Slice:
> https://github.com/joeduffy/slice.net/blob/master/README.md.  Being able
> to
> overlay a typesafe and cheap struct on top of a byte buffer would save some
> boilerplate coding.
>
> sent from my phone
> On Nov 18, 2015 6:52 PM, "John Rose" <john.r.rose at oracle.com> wrote:
>
> > On Nov 18, 2015, at 12:36 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >
> >
> > Note that while values are in part about getting flatter data layouts, we
> > do not plan to offer anything in the way of fine-grained layout control,
> > such as allowing for explicit alignment requirements.  (Though other
> > efforts, such as Project Panama, may have something to offer here).
> >
> >
> > Right; it's easier on the JVM to let it have its own choice on layouts.
> >
> > For example, HotSpot usually repacks object fields so that refs
> > are all together, longs/doubles all together, ints/floats together,
> > etc., to minimize fragmentation and certain GC overheads.
> > Value types are likely to play such games also.
> >
> > Open question:  How valuable would it be to "export" JVM-laid-out
> > values off heap?  My take:  Not a killer feature if done via bitwise
> > copies, since off-heap storage often needs an externally defined
> > layout.  But, perhaps we could define a mapping (or several
> > mappings) from value types to native types, and build copy
> > operations into Panama.  Simple types like complex<double>
> > should copy bitwise between heaps, even other types like
> > tuple<long, boolean, long> do not.  The main point is that
> > Panama expects to take data schemas from multiple
> > sources (not just C/C++), and that will play well with
> > value types.
> >
> > ? John
> >
>

From vitalyd at gmail.com  Thu Nov 19 03:37:28 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Nov 2015 22:37:28 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAMaYbvJ3EadsHVCPbNfZSmyd3M2ErQ48jP5xi-eYLVDbu_2RLA@mail.gmail.com>
References: <CAMaYbv+5m3cAb_7ToOO0Qe_ZCgEf-bq7mhO1xiHUO8yO9+E=uA@mail.gmail.com>
	<CAAWwtm9mFtpjimDia=5sddq6OkRGe23ce1mcqUmsYErU3jLQ0Q@mail.gmail.com>
	<CAHjP37Fa2TJ1Fnz2mLE3hXztbpzkQ8FtiO8oJj4J7tPtbxYU9A@mail.gmail.com>
	<CAAWwtm_5GJ61x8tGDHKybZHeintke3iKWL5mb=cZJz8DmOmhvg@mail.gmail.com>
	<D2727832.11176B%duncan.macgregor@ge.com>
	<CAHjP37GudPAzzJRYOGJ9Hc0074Oak+9P315v9NMkqB88RTtCQA@mail.gmail.com>
	<564cce80.46b71c0a.1ddcf.ffffd239@mx.google.com>
	<CAHjP37E854PAir=1iVVFEj0FHNuYxY1MfDN5nDHe61N=k+ctdA@mail.gmail.com>
	<CAAWwtm-XZzKQmMfMhourTmqWehn2Rghv5zWgyv6ObbV8gPzL-A@mail.gmail.com>
	<564CE162.2010107@oracle.com>
	<75682841-8AC7-44ED-BE05-96906F888423@oracle.com>
	<CAHjP37H54BoSphfc_3tT=1RmJPeRK9tHQnbfP_14nM-jEjc2Rw@mail.gmail.com>
	<CAMaYbvJ3EadsHVCPbNfZSmyd3M2ErQ48jP5xi-eYLVDbu_2RLA@mail.gmail.com>
Message-ID: <CAHjP37GgiWuJm90u_d-UXUpjcXmxe-nsrqjx-vhFi8_eidnekw@mail.gmail.com>

John mentioned Panama and possible synergies with Valhalla, and asked about
layout so I jumped in :).  Defining a struct whose layout matches that of a
piece of memory is highly useful, so we have struct + layout, seemed
relevant :).

sent from my phone
On Nov 18, 2015 10:27 PM, "Richard Warburton" <richard.warburton at gmail.com>
wrote:

> Hi,
>
> Vitaly: so would I but are you sure that that use case should be part of
> Valhalla? It seems highly orthogonal to value types. The only thing they
> have in common is a different memory layout from Java objects.
> On 18 Nov 2015 15:58, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
>
>> Personally, I'd love to see layout and alignment exposed.  I'd also like
>> to
>> see something like this Slice:
>> https://github.com/joeduffy/slice.net/blob/master/README.md.  Being able
>> to
>> overlay a typesafe and cheap struct on top of a byte buffer would save
>> some
>> boilerplate coding.
>>
>> sent from my phone
>> On Nov 18, 2015 6:52 PM, "John Rose" <john.r.rose at oracle.com> wrote:
>>
>> > On Nov 18, 2015, at 12:36 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> >
>> >
>> > Note that while values are in part about getting flatter data layouts,
>> we
>> > do not plan to offer anything in the way of fine-grained layout control,
>> > such as allowing for explicit alignment requirements.  (Though other
>> > efforts, such as Project Panama, may have something to offer here).
>> >
>> >
>> > Right; it's easier on the JVM to let it have its own choice on layouts.
>> >
>> > For example, HotSpot usually repacks object fields so that refs
>> > are all together, longs/doubles all together, ints/floats together,
>> > etc., to minimize fragmentation and certain GC overheads.
>> > Value types are likely to play such games also.
>> >
>> > Open question:  How valuable would it be to "export" JVM-laid-out
>> > values off heap?  My take:  Not a killer feature if done via bitwise
>> > copies, since off-heap storage often needs an externally defined
>> > layout.  But, perhaps we could define a mapping (or several
>> > mappings) from value types to native types, and build copy
>> > operations into Panama.  Simple types like complex<double>
>> > should copy bitwise between heaps, even other types like
>> > tuple<long, boolean, long> do not.  The main point is that
>> > Panama expects to take data schemas from multiple
>> > sources (not just C/C++), and that will play well with
>> > value types.
>> >
>> > ? John
>> >
>>
>

From john.r.rose at oracle.com  Thu Nov 19 04:28:21 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 20:28:21 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <CAHjP37GZ97Tph5893MVV4U9bSG0vS9KBXDesanOQmKF8RUneVw@mail.gmail.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
	<72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
	<CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
	<EA8D2B7D-E1ED-4FBC-B838-0E8FE774F414@oracle.com>
	<CAHjP37GZ97Tph5893MVV4U9bSG0vS9KBXDesanOQmKF8RUneVw@mail.gmail.com>
Message-ID: <29AE1940-868C-4B8E-AFA6-0EC548DE9E06@oracle.com>

On Nov 18, 2015, at 6:18 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Also, you can have "lost" writes even with immutable types, e.g.:
> 
> MyMutableInt x = new ...
> x.add(...); oops forgot to assign to new local
> 
*That* needs a linty language feature:

interface ImmList<T> {
  @Unavoidable  // do not discard this value without a complaint
  ImmList<T> add(T);
}


From john.r.rose at oracle.com  Thu Nov 19 04:43:45 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2015 20:43:45 -0800
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>

On Nov 18, 2015, at 5:15 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com> wrote:
> 
> From a Valhalla perspective, the fact that one cannot manufacture a sentinel besides T.default is a real problem for collections that need more than one sentinel. The current types (primitives, references) don?t have this limitation.

The int type has such a limitation, in that somebody has to choose (and manufacture) an int value the doesn't look like a valid payload.

> (This is also not a problem in languages like C where I can cast a struct to char* and fill it with arbitrary bit patterns).

OK, I'll bite.  If this is important enough, we can generalize optional<T> to a new wrapper type that allocates more than one extra bit pattern.  Suppose there were a value type sentinel<T,X>, where X is a type unique to the sentinel usage, backed by T plus "epsilon" bits.  The "epsilon" is enough to distinguish the X state from any similar state (or the optional.isPresent state) in the underlying type T.  I'm not saying this is easy or natural to express in the JVM, but it logically expresses the requirement.

class MyQueue<T> {
  private sentinel<optional<T>,MyQueue>[] buf;
  ?
  private atSentinel() { return buf[current].isSentinel(X.class); }
  public optional<T> getOptional() { return buf[current].getNonSentinel(X.class); }
  public T get() { return getOptional().get(); }
}

The naive implementation is that, like optional, each layer of "sentinel-ness" adds an extra boolean of envelope around the underlying value.  But, given some ad hoc JVM optimizations, some day, up to 255 sentinel and optional layers could share a tag byte expressing the various possible levels of "not present", and/or use the T payload itself to express many (2**32) layers of "not present" with an extra bit of tag.  Thus, "epsilon" can be 8 or even 1.

In the tag-byte case (eps = 8), this gives you up to 255 sentinel values per value type.  Now, if you add another trick to the JVM, it could notice if T has slack bits in it (uncompressed pointers have 3-4 slack bits, while doubles have over 50 slack bits) and place the "not present" codes into the T bits, with no additional tags, not even one bit.  In that case, "epsilon" = 0 and everybody is happy, since they have re-invented "null", but everybody gets their own "null" (the X parameter).

This stuff *can* be done, and maybe in the future we will decide to do it.  (Optimization budget, right Vitaly?)  By making the JVM master of the value type layouts, we can reserve the option to make such optimizations.

? John

From vitalyd at gmail.com  Thu Nov 19 05:10:23 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 19 Nov 2015 00:10:23 -0500
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
	<D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>
Message-ID: <CAHjP37Ezb8LWWZ-zkitw4kwm75fTrZd0fK9ze6h8PiiuuETttA@mail.gmail.com>

This is an interesting idea.

How would this work with methods that check if incoming argument is equal
to a sentinel value, as an example? You'd want to use T.equals() for that,
but what do you pass it to compare? If the sentinel bit pattern is not
"stolen" from T itself and instead enveloped, how does one express that
without removing the envelope so to speak?

Maybe the right answer here is to punt this to specialization and allow
author to write specialized versions for specific Ts it knows how to
optimize.  This is assuming someone really doesn't want the extra byte +
alignment overhead in Moh's 3(a) approach.  Alternatively, force T to
provide constructor that takes a byte (or whatever sentinel type) via a new
generic constraint.

Right on about optimization budget John :).

sent from my phone
On Nov 18, 2015 11:43 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 5:15 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com>
> wrote:
>
>
> From a Valhalla perspective, the fact that one cannot manufacture a
> sentinel besides T.default is a real problem for collections that need more
> than one sentinel. The current types (primitives, references) don?t have
> this limitation.
>
>
> The int type has such a limitation, in that somebody has to choose (and
> manufacture) an int value the doesn't look like a valid payload.
>
> (This is also not a problem in languages like C where I can cast a struct
> to char* and fill it with arbitrary bit patterns).
>
>
> OK, I'll bite.  If this is important enough, we can generalize optional<T>
> to a new wrapper type that allocates more than one extra bit pattern.
> Suppose there were a value type sentinel<T,X>, where X is a type unique to
> the sentinel usage, backed by T plus "epsilon" bits.  The "epsilon" is
> enough to distinguish the X state from any similar state (or the
> optional.isPresent state) in the underlying type T.  I'm not saying this is
> easy or natural to express in the JVM, but it logically expresses the
> requirement.
>
> class MyQueue<T> {
>   private sentinel<optional<T>,MyQueue>[] buf;
>   ?
>   private atSentinel() { return buf[current].isSentinel(X.class); }
>   public optional<T> getOptional() { return
> buf[current].getNonSentinel(X.class); }
>   public T get() { return getOptional().get(); }
> }
>
> The naive implementation is that, like optional, each layer of
> "sentinel-ness" adds an extra boolean of envelope around the underlying
> value.  But, given some ad hoc JVM optimizations, some day, up to 255
> sentinel and optional layers could share a tag byte expressing the various
> possible levels of "not present", and/or use the T payload itself to
> express many (2**32) layers of "not present" with an extra bit of tag.
> Thus, "epsilon" can be 8 or even 1.
>
> In the tag-byte case (eps = 8), this gives you up to 255 sentinel values
> per value type.  Now, if you add another trick to the JVM, it could notice
> if T has slack bits in it (uncompressed pointers have 3-4 slack bits, while
> doubles have over 50 slack bits) and place the "not present" codes into the
> T bits, with no additional tags, not even one bit.  In that case, "epsilon"
> = 0 and everybody is happy, since they have re-invented "null", but
> everybody gets their own "null" (the X parameter).
>
> This stuff *can* be done, and maybe in the future we will decide to do it.
>  (Optimization budget, right Vitaly?)  By making the JVM master of the
> value type layouts, we can reserve the option to make such optimizations.
>
> ? John
>

From michael.hixson at gmail.com  Thu Nov 19 07:11:04 2015
From: michael.hixson at gmail.com (Michael Hixson)
Date: Wed, 18 Nov 2015 23:11:04 -0800
Subject: Primitive Queue<any T> considerations
In-Reply-To: <29AE1940-868C-4B8E-AFA6-0EC548DE9E06@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<C75021D9-B8E4-4D05-998B-40B9D54D9BB3@oracle.com>
	<CAHjP37EobACsy+47VeL0CfWucLsi2mq+cVu_RioTi5YXd07Bzg@mail.gmail.com>
	<72361CCC-9BD7-45F9-A03E-C27DBDEBF2E2@oracle.com>
	<CAHjP37G4iC9mFs+Qr=kTR=+-pPSmt0gCDkOk64DjByMSEG3Tsg@mail.gmail.com>
	<EA8D2B7D-E1ED-4FBC-B838-0E8FE774F414@oracle.com>
	<CAHjP37GZ97Tph5893MVV4U9bSG0vS9KBXDesanOQmKF8RUneVw@mail.gmail.com>
	<29AE1940-868C-4B8E-AFA6-0EC548DE9E06@oracle.com>
Message-ID: <CAHqckpMYPR919r8EqJ7vrSHnxm_=Z+TNrpih1tvwkf+kqnqz7g@mail.gmail.com>

On Wed, Nov 18, 2015 at 8:28 PM, John Rose <john.r.rose at oracle.com> wrote:
> On Nov 18, 2015, at 6:18 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>> Also, you can have "lost" writes even with immutable types, e.g.:
>>
>> MyMutableInt x = new ...
>> x.add(...); oops forgot to assign to new local
>>
> *That* needs a linty language feature:
>
> interface ImmList<T> {
>   @Unavoidable  // do not discard this value without a complaint
>   ImmList<T> add(T);
> }
>

It seems like jsr305 / FindBugs have this covered with
@CheckReturnValue, right?  Not sure if there is IDE/tooling support
for inferring that annotation on certain JDK methods though, like
there is for nullness.

http://findbugs.sourceforge.net/api/edu/umd/cs/findbugs/annotations/CheckReturnValue.html

-Michael

From maurizio.cimadamore at oracle.com  Thu Nov 19 10:59:38 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 19 Nov 2015 10:59:38 +0000
Subject: hg: valhalla/valhalla/langtools: 2 new changesets
Message-ID: <201511191059.tAJAxcLZ011588@aojmv0008.oracle.com>

Changeset: 8a2e511aeaa6
Author:    mcimadamore
Date:      2015-11-19 10:39 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8a2e511aeaa6

Fix: Javac should enforce that a value type cannot declare a field of its own type either directly or indirectly.
Contributed-by: srikanth.adayapalam at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties

Changeset: a78ce07fb6a9
Author:    mcimadamore
Date:      2015-11-19 10:39 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a78ce07fb6a9

Fix: Compiler should disallow assignment of null to value types.
Contributed-by: srikanth.adayapalam at oracle.com

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


From maurizio.cimadamore at oracle.com  Thu Nov 19 11:00:51 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 19 Nov 2015 11:00:51 +0000
Subject: hg: valhalla/valhalla/langtools: Forgot to hg add tests
Message-ID: <201511191100.tAJB0pi7012253@aojmv0008.oracle.com>

Changeset: 35edb8f7ce32
Author:    mcimadamore
Date:      2015-11-19 11:00 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/35edb8f7ce32

Forgot to hg add tests

+ test/tools/javac/diags/examples/RecursiveValueType.java
+ test/tools/javac/valhalla/values/CheckCyclicMembership.java
+ test/tools/javac/valhalla/values/CheckCyclicMembership.out
+ test/tools/javac/valhalla/values/CheckNullAssign.java
+ test/tools/javac/valhalla/values/CheckNullAssign.out


From dl at cs.oswego.edu  Thu Nov 19 12:35:42 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 19 Nov 2015 07:35:42 -0500
Subject: Primitive Queue<any T> considerations
In-Reply-To: <DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>
References: <CAAWwtm-W8HZuSM88WPfB=TkibaE_9U--Mi+JzXKZVB8RkO1ZJQ@mail.gmail.com>
	<564CA69B.10700@oracle.com>
	<CAHjP37FUB6CyR0H2_yF6-UoOEtxtdFb-MZkTpQgr2sXGX9bBQg@mail.gmail.com>
	<CAAWwtm_VoTYSfsCTq3zDL3On0C79ZR1SbOTqW89FLcr_1fceGg@mail.gmail.com>
	<564CD7E6.3050103@oracle.com>
	<CAHjP37G0CaGO9VmTLMxX0qVtwcTaAC7fnCUFCOi1jWow+bgnuw@mail.gmail.com>
	<564CDA8F.9020303@oracle.com>
	<CAHjP37GQysW3-smbTdJ1=WNyZZPjcpDJnNkwna41o4sL3CFeTw@mail.gmail.com>
	<564CDE8D.1040308@oracle.com>
	<CAHjP37EjoY6shHU3ixX4w17pG47oPpnro5nLZy4rUGjr6v7OUw@mail.gmail.com>
	<DB644332-8485-4F07-8CD5-6EA2E88B3E25@oracle.com>
Message-ID: <564DC21E.1020001@cs.oswego.edu>


We considered most of these issues when designing jdk8 Spliterator,
which was created with possible any-fication in mind
(and emulated in jdk8 IntStream etc). This led to using
   boolean Spliterator::tryAdvance(Consumer<T> action)

This avoids need for defaults or shadow bits or boxes,
at the expense of placing more pressure on optimizing
lambdas, which can still be an issue.

We briefly considered also adding the similar
   boolean Queue::tryConsume(Consumer<T> action)
... and similarly in a few other APIs. In retrospect, we probably ought
to have done this in jdk8, since it seems almost inevitable that
they will be added when any-fication happens.
People don't have to use them of course, but when they don't,
they will have to rely on boxing and/or Optional for
possibly-null-returning methods.

-Doug


From Mohammad.Rezaei at gs.com  Thu Nov 19 15:19:10 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Thu, 19 Nov 2015 10:19:10 -0500
Subject: Sentinels in collections, was RE: Primitive Queue<any T>
	considerations
In-Reply-To: <D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
	<D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>
Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E1BD@GSCMAMP06EX.firmwide.corp.gs.com>

On Nov 18, 2015 11:43 PM, "John Rose" <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:

                The int type has such a limitation, in that somebody has to choose (and manufacture) an int value the doesn't look like a valid payload.

That?s true if we?re talking about the Valhalla reified type int. For the plain old primitive int, that?s not the case. For contrast with code a bit further down, I?ll write it out:

public class IntHashSet {  // all possible values can be used by the user.
                private static final int EMPTY = 0; // does not leak outside
                private static final int REMOVED = 1; // does not leak outside
                private int[] entries; // contains EMPTY, REMOVED or user provided value
                private byte oneAndZero; // stores the set?s containment of 0 and 1

                public void add(int v) {
                                if (v == EMPTY) oneAnZero |= 1;
                                else if (v == REMOVED) oneAndZero |= 2;
                                else addToEntries(v);
                }

private void addToEntries(int v) {
                int index = indexOf(v);
                if (entries[index] == EMTPY || entries[index] == REMOVED || entries[index] == v) entries[index] = v;
                else findAnotherSlot(v);
};
}

Similar treatment works for map<int, V>.

If we?re willing to pay for a tag, and occasionally get lucky and pay nothing, all sorts of possibilities open up. From a complexity/optimization budget perspective, I?d rather see that spent on a more general purpose concept: union types. The above code would look like this with union types (excuse the syntax):

public class AnyfiedSet<any V> {
                private static __value EMPTY {} // member-less value type
                private static __value REMOVED {} // member-less value type
                private static __unionType STORAGE_TYPE { EMPTY, RESERVED, V}

                private STORAGE_TYPE[] entries;

                public void add(V v)
                {
                                // Vitaly, with tagged structures, you wouldn?t examine v at this point, but we?ll need instanceof or a way to examine the tag
                                int index = indexOf(v);
// == becomes instanceof:
                                if (entries[index] instanceof EMPTY || entries[index] instanceof REMOVED || entries[index] instanceof V && ((V)entries[index])== v)
entries[index] = v;
                                else findAnotherSlot(v);
                }
}

Sadly, no amount of optimization will make this as good as the first implementation for the existing crop of integer-like primitives. While primitive collections libraries will benefit from any-fied interfaces, for the highly optimized space they compete in, there will be a per-type implementation even with Valhalla.

I?m generally a fan of letting the VM pick the layout, so long as I can query it (reflection, unsafe, etc). That does open up a lot of optimization as you mention below. In particular, your sentinel proposal can be subsumed into yet another useful construct: enum value type. If I can defined:

                __enum_value Sentinel {EMPTY, REMOVED, UNSENTINEL}

Then all I need is a Pair<Sentinel, V> and the VM can decide to fit all the bits in the storage of V, if V has 2 extra bits to spare.

Thanks
Moh

From: John Rose [mailto:john.r.rose at oracle.com]
Sent: Wednesday, November 18, 2015 11:44 PM
To: Rezaei, Mohammad A. [Tech]
Cc: Vitaly Davidovich; Richard Warburton; valhalla-dev at openjdk.java.net
Subject: Re: Sentinels in collections, was RE: Primitive Queue<any T> considerations

On Nov 18, 2015, at 5:15 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com<mailto:Mohammad.Rezaei at gs.com>> wrote:

From a Valhalla perspective, the fact that one cannot manufacture a sentinel besides T.default is a real problem for collections that need more than one sentinel. The current types (primitives, references) don?t have this limitation.



(This is also not a problem in languages like C where I can cast a struct to char* and fill it with arbitrary bit patterns).

OK, I'll bite.  If this is important enough, we can generalize optional<T> to a new wrapper type that allocates more than one extra bit pattern.  Suppose there were a value type sentinel<T,X>, where X is a type unique to the sentinel usage, backed by T plus "epsilon" bits.  The "epsilon" is enough to distinguish the X state from any similar state (or the optional.isPresent state) in the underlying type T.  I'm not saying this is easy or natural to express in the JVM, but it logically expresses the requirement.

[1]class MyQueue<T> {
  private sentinel<optional<T>,MyQueue>[] buf;
  ?
  private atSentinel() { return buf[current].isSentinel(X.class); }
  public optional<T> getOptional() { return buf[current].getNonSentinel(X.class); }
  public T get() { return getOptional().get(); }
}

The naive implementation is that, like optional, each layer of "sentinel-ness" adds an extra boolean of envelope around the underlying value.  But, given some ad hoc JVM optimizations, some day, up to 255 sentinel and optional layers could share a tag byte expressing the various possible levels of "not present", and/or use the T payload itself to express many (2**32) layers of "not present" with an extra bit of tag.  Thus, "epsilon" can be 8 or even 1.

In the tag-byte case (eps = 8), this gives you up to 255 sentinel values per value type.  Now, if you add another trick to the JVM, it could notice if T has slack bits in it (uncompressed pointers have 3-4 slack bits, while doubles have over 50 slack bits) and place the "not present" codes into the T bits, with no additional tags, not even one bit.  In that case, "epsilon" = 0 and everybody is happy, since they have re-invented "null", but everybody gets their own "null" (the X parameter).

This stuff *can* be done, and maybe in the future we will decide to do it.  (Optimization budget, right Vitaly?)  By making the JVM master of the value type layouts, we can reserve the option to make such optimizations.

? John

From john.r.rose at oracle.com  Thu Nov 19 23:48:18 2015
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 19 Nov 2015 15:48:18 -0800
Subject: Sentinels in collections,
	was RE: Primitive Queue<any T> considerations
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E1BD@GSCMAMP06EX.firmwide.corp.gs.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
	<D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E1BD@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <7FDE4E9E-C883-480C-AFC4-0F0DD0ACC35B@oracle.com>

On Nov 19, 2015, at 7:19 AM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com> wrote:
> 
> If we?re willing to pay for a tag, and occasionally get lucky and pay nothing, all sorts of possibilities open up. From a complexity/optimization budget perspective, I?d rather see that spent on a more general purpose concept: union types. The above code would look like this with union types (excuse the syntax):

Good point!  Tagged unions have a number of interesting tricks they can play for data structure layout and packing.

Adding a sentinel to a type with slack bits can be generalized slightly by adding another small type.
For example, the type double has about 50 slack bits, which are enough to code all other basic types, except long.
A sentinel can be viewed as a unit type (like void or null, of zero bits and one value).
A coproduct (union) of two types requires enough bits to represent all points of either type.
So if the larger type has enough unused code points to represent the smaller type, we win.
Otherwise we need an extra bit to manufacture more code points.

There are various proposals to do tagged unions in the JVM; see for example:
 http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-July/004665.html (shrink long to 63 bits to introduce slack)
 http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0afdd88556bc (add new basictype)


? John

From timo.kinnunen at gmail.com  Fri Nov 20 05:21:32 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Fri, 20 Nov 2015 06:21:32 +0100
Subject: Sentinels in collections, was RE: Primitive Queue<any
	T>considerations
In-Reply-To: <7FDE4E9E-C883-480C-AFC4-0F0DD0ACC35B@oracle.com>
References: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E152@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37Fbh1YBbGXtsQYL5xpyf6dVuQdYPgiv8mkQ7wjDDqq9dQ@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E169@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAHjP37EQdcuLbwqxm7WZpk+qoL5N8M3fa8UGhWnON4n5aYpBDw@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E16E@GSCMAMP06EX.firmwide.corp.gs.com>
	<CAMaYbvKZRG5paLTPt82AuopzTrpea6fzBgjYTd4c_s2rDF6VqA@mail.gmail.com>
	<CAHjP37E0CDU0tzQ=hc-Y8nhg1=MHeW_QOPKTix=rbotJd=QR0g@mail.gmail.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E195@GSCMAMP06EX.firmwide.corp.gs.com>
	<D300C132-4941-4B14-AC91-B8CC231DF308@oracle.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D208647E1BD@GSCMAMP06EX.firmwide.corp.gs.com>
	<7FDE4E9E-C883-480C-AFC4-0F0DD0ACC35B@oracle.com>
Message-ID: <564eadf1.043fc20a.18c22.ffffa145@mx.google.com>

Yes, now that you mention, being able to type-specialize over value types and void to do something like this is going to be really nice:

	// In a Map<T, U> kind of API:
	// ?
	<R=U, R=void, T=K> // all of these are true, just not simultaneously
	public R get(K key) {
		int at = index(key);
		if(at == -1) return void;
		return table[at+1];
	}

	// In a caller:
	Map<long, long> longMap = //?
	<L> L value = longMap.get(key);
	if(<L=void>) {
		return NOT_FOUND;    // value is not even in scope here
	}                                                      // implicit else block with L is long starting from here
	value += 1;                                    // no need for unboxing
	longMap.put(key, value);          // no trace of void either
	// etc..
	


This is lot cooler than having nullable boxes of values and using them just return a null, and unlike null a void can?t ever be forgotten about and not get checked.



Sent from Mail for Windows 10



From: John Rose
Sent: Friday, November 20, 2015 00:48
To: Rezaei, Mohammad A.
Cc: valhalla-dev at openjdk.java.net
Subject: Re: Sentinels in collections, was RE: Primitive Queueconsiderations


On Nov 19, 2015, at 7:19 AM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com> wrote:
> 
> If we?re willing to pay for a tag, and occasionally get lucky and pay nothing, all sorts of possibilities open up. From a complexity/optimization budget perspective, I?d rather see that spent on a more general purpose concept: union types. The above code would look like this with union types (excuse the syntax):

Good point!  Tagged unions have a number of interesting tricks they can play for data structure layout and packing.

Adding a sentinel to a type with slack bits can be generalized slightly by adding another small type.
For example, the type double has about 50 slack bits, which are enough to code all other basic types, except long.
A sentinel can be viewed as a unit type (like void or null, of zero bits and one value).
A coproduct (union) of two types requires enough bits to represent all points of either type.
So if the larger type has enough unused code points to represent the smaller type, we win.
Otherwise we need an extra bit to manufacture more code points.

There are various proposals to do tagged unions in the JVM; see for example:
 http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-July/004665.html (shrink long to 63 bits to introduce slack)
 http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0afdd88556bc (add new basictype)


? John



From maurizio.cimadamore at oracle.com  Fri Nov 20 11:40:40 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 20 Nov 2015 11:40:40 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Compiler should reject value
	modifier when it features in illegal contexts
Message-ID: <201511201140.tAKBeeVC006035@aojmv0008.oracle.com>

Changeset: ec27ff1cb372
Author:    mcimadamore
Date:      2015-11-20 11:40 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ec27ff1cb372

Fix: Compiler should reject value modifier when it features in illegal contexts
Contributed-by: srikanth.adayapalam at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/valhalla/values/CheckValueModifier.java
+ test/tools/javac/valhalla/values/CheckValueModifier.out


From maurizio.cimadamore at oracle.com  Fri Nov 20 14:00:45 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 20 Nov 2015 14:00:45 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Do not allow mismatched
	instantiation syntax between value & reference types.
Message-ID: <201511201400.tAKE0jlS025911@aojmv0008.oracle.com>

Changeset: e5262162667f
Author:    mcimadamore
Date:      2015-11-20 14:00 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e5262162667f

Fix: Do not allow mismatched instantiation syntax between value & reference types.
Contributed-by: srikanth.adayapalam at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/GarbledValueReferenceInstantiation.java
+ test/tools/javac/valhalla/values/CheckValueFactoryWithReference.java
+ test/tools/javac/valhalla/values/CheckValueFactoryWithReference.out


From maurizio.cimadamore at oracle.com  Fri Nov 20 14:07:29 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 20 Nov 2015 14:07:29 +0000
Subject: CFV: New Valhalla Committer: Srikanth Adayapalam
Message-ID: <564F2921.8020700@oracle.com>

I hereby nominate Srikanth.Adayapalam (sadayapalam) to Valhalla Committer.

Srikanth is a member of the Langtools team who's looking forward to work 
on the compiler-side implementation of value types. Here's a list of his 
OpenJDK contributions in the scope of Project Valhalla.

http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e5262162667f
http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ec27ff1cb372
http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a78ce07fb6a9
http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8a2e511aeaa6
http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/eb59ce39c7b0

And below is a list of his JDK 9 contributions:

http://hg.openjdk.java.net/jdk9/dev/langtools/search/?rev=sadayapalam&revcount=80

Votes are due by December 5, 2015.

Only current Valhalla Committers [1] are eligible to vote on this
nomination.

For Lazy Consensus voting instructions, see [2].

Thank you,
Maurizio Cimadamore

[1] - http://openjdk.java.net/census
[2] - http://openjdk.java.net/projects/#committer-vote



From paul.sandoz at oracle.com  Fri Nov 20 17:56:14 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Nov 2015 18:56:14 +0100
Subject: CFV: New Valhalla Committer: Srikanth Adayapalam
In-Reply-To: <564F2921.8020700@oracle.com>
References: <564F2921.8020700@oracle.com>
Message-ID: <D88C816C-6285-4150-9F1F-784E4A1B0F7F@oracle.com>

Vote: yes.

Paul.

From brian.goetz at oracle.com  Fri Nov 20 20:18:57 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 20 Nov 2015 15:18:57 -0500
Subject: CFV: New Valhalla Committer: Srikanth Adayapalam
In-Reply-To: <564F2921.8020700@oracle.com>
References: <564F2921.8020700@oracle.com>
Message-ID: <564F8031.1010807@oracle.com>

Vote: yes

On 11/20/2015 9:07 AM, Maurizio Cimadamore wrote:
> I hereby nominate Srikanth.Adayapalam (sadayapalam) to Valhalla 
> Committer.
>
> Srikanth is a member of the Langtools team who's looking forward to 
> work on the compiler-side implementation of value types. Here's a list 
> of his OpenJDK contributions in the scope of Project Valhalla.
>
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e5262162667f
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ec27ff1cb372
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a78ce07fb6a9
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/8a2e511aeaa6
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/eb59ce39c7b0
>
> And below is a list of his JDK 9 contributions:
>
> http://hg.openjdk.java.net/jdk9/dev/langtools/search/?rev=sadayapalam&revcount=80 
>
>
> Votes are due by December 5, 2015.
>
> Only current Valhalla Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thank you,
> Maurizio Cimadamore
>
> [1] - http://openjdk.java.net/census
> [2] - http://openjdk.java.net/projects/#committer-vote
>
>


From john.r.rose at oracle.com  Sat Nov 21 02:28:49 2015
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Nov 2015 18:28:49 -0800
Subject: CFV: New Valhalla Committer: Srikanth Adayapalam
In-Reply-To: <564F2921.8020700@oracle.com>
References: <564F2921.8020700@oracle.com>
Message-ID: <2B5BED34-C243-4E3F-BC29-EF64E8F64437@oracle.com>

Vote: yes

From srikanth.adayapalam at oracle.com  Mon Nov 23 08:40:31 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 23 Nov 2015 14:10:31 +0530
Subject: java.lang.__Value ??
Message-ID: <5652D0FF.6000502@oracle.com>


Hello !

valhalla/src/java.base/share/classes/java/lang/__Value.java

starts with:

package java.lang;

/**
  * Base class of all value types in prototype implementation.
  */
__ByValue final public class __Value {
// ...
}

It seems to me that this class (a) should not be final (b) not carry the 
decoration
__ByValue. (c) Is better named just Value rather than __Value - this 
being a type
name in a name space controlled by JDK. (d) should perhaps be declared 
abstract.

Also,

Given:

__ByValue final class X {
     public static void main(String [] args) {
         System.out.println("Hello");
     }
}

at the moment the class file generated by javac[*] encodes an explicit 
super type:

final value class X extends java.lang.__Value

It would appear the right behavior is to leave the supertype implicit and be
inferred from the ACC_VALUE flag bit being set.


[*] The class file generated cannot be run as of now - since 'Q' in 
signatures is not digested
by the VM yet. But using a modified version of javac that emits 'L' even 
for value types
I am able to run the program above triggering:

Exception in thread "main" java.lang.VerifyError: Cannot inherit from 
final class

Srikanth.

From maurizio.cimadamore at oracle.com  Mon Nov 23 11:25:52 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 23 Nov 2015 11:25:52 +0000
Subject: java.lang.__Value ??
In-Reply-To: <5652D0FF.6000502@oracle.com>
References: <5652D0FF.6000502@oracle.com>
Message-ID: <5652F7C0.2080001@oracle.com>

I think the current set of modifiers is being relied upon by the JVM; 
more specifically, it's easier for the VM if the root of all values 
doesn't extend j.l.Object (for now at least).

Maurizio

On 23/11/15 08:40, Srikanth wrote:
>
> Hello !
>
> valhalla/src/java.base/share/classes/java/lang/__Value.java
>
> starts with:
>
> package java.lang;
>
> /**
>  * Base class of all value types in prototype implementation.
>  */
> __ByValue final public class __Value {
> // ...
> }
>
> It seems to me that this class (a) should not be final (b) not carry 
> the decoration
> __ByValue. (c) Is better named just Value rather than __Value - this 
> being a type
> name in a name space controlled by JDK. (d) should perhaps be declared 
> abstract.
>
> Also,
>
> Given:
>
> __ByValue final class X {
>     public static void main(String [] args) {
>         System.out.println("Hello");
>     }
> }
>
> at the moment the class file generated by javac[*] encodes an explicit 
> super type:
>
> final value class X extends java.lang.__Value
>
> It would appear the right behavior is to leave the supertype implicit 
> and be
> inferred from the ACC_VALUE flag bit being set.
>
>
> [*] The class file generated cannot be run as of now - since 'Q' in 
> signatures is not digested
> by the VM yet. But using a modified version of javac that emits 'L' 
> even for value types
> I am able to run the program above triggering:
>
> Exception in thread "main" java.lang.VerifyError: Cannot inherit from 
> final class
>
> Srikanth.


From srikanth.adayapalam at oracle.com  Mon Nov 23 11:39:55 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 23 Nov 2015 17:09:55 +0530
Subject: java.lang.__Value ??
In-Reply-To: <5652F7C0.2080001@oracle.com>
References: <5652D0FF.6000502@oracle.com> <5652F7C0.2080001@oracle.com>
Message-ID: <5652FB0B.9000808@oracle.com>



On Monday 23 November 2015 04:55 PM, Maurizio Cimadamore wrote:
> I think the current set of modifiers is being relied upon by the JVM; 
> more specifically, it's easier for the VM if the root of all values 
> doesn't extend j.l.Object (for now at least).

Hi Maurzio,

The current set of modifiers is wrong - as my previous mail showed, 
having j.l.__Value as a final class will trigger verify errors.
Without knowing the rationale for the present state of affairs it also 
looks odd to me that it would be tagged __ByValue and
that it is not abstract.

Presently, javac wires j.l.__Value to be a root and not extend j.l.O and 
I am not at all suggesting this be changed.

[BTW, I misspoke about the explicit vs implicit mention of super types 
in class files. There is no open question there]

Thanks!
Srikanth

>
> Maurizio
>
> On 23/11/15 08:40, Srikanth wrote:
>>
>> Hello !
>>
>> valhalla/src/java.base/share/classes/java/lang/__Value.java
>>
>> starts with:
>>
>> package java.lang;
>>
>> /**
>>  * Base class of all value types in prototype implementation.
>>  */
>> __ByValue final public class __Value {
>> // ...
>> }
>>
>> It seems to me that this class (a) should not be final (b) not carry 
>> the decoration
>> __ByValue. (c) Is better named just Value rather than __Value - this 
>> being a type
>> name in a name space controlled by JDK. (d) should perhaps be 
>> declared abstract.
>>
>> Also,
>>
>> Given:
>>
>> __ByValue final class X {
>>     public static void main(String [] args) {
>>         System.out.println("Hello");
>>     }
>> }
>>
>> at the moment the class file generated by javac[*] encodes an 
>> explicit super type:
>>
>> final value class X extends java.lang.__Value
>>
>> It would appear the right behavior is to leave the supertype implicit 
>> and be
>> inferred from the ACC_VALUE flag bit being set.
>>
>>
>> [*] The class file generated cannot be run as of now - since 'Q' in 
>> signatures is not digested
>> by the VM yet. But using a modified version of javac that emits 'L' 
>> even for value types
>> I am able to run the program above triggering:
>>
>> Exception in thread "main" java.lang.VerifyError: Cannot inherit from 
>> final class
>>
>> Srikanth.
>


From maurizio.cimadamore at oracle.com  Mon Nov 23 11:40:21 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 23 Nov 2015 11:40:21 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Verify that value types have
	their super type wired properly.
Message-ID: <201511231140.tANBeMgE025826@aojmv0008.oracle.com>

Changeset: e89e4eee7e7e
Author:    mcimadamore
Date:      2015-11-23 11:39 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e89e4eee7e7e

Fix: Verify that value types have their super type wired properly.
Contributed-by: srikanth.adayapalam at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
! test/tools/javac/valhalla/values/CheckSuper.java
+ test/tools/javac/valhalla/values/CheckSuperCompileOnly.java


From brian.goetz at oracle.com  Mon Nov 23 16:40:51 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 23 Nov 2015 11:40:51 -0500
Subject: java.lang.__Value ??
In-Reply-To: <5652D0FF.6000502@oracle.com>
References: <5652D0FF.6000502@oracle.com>
Message-ID: <56534193.1030209@oracle.com>

[ adding background ]

The __Value type as it currently stands is simply a placeholder for the 
current round of compiler experiments (hence the deliberately horrible 
name).

In the long run, we need:
  - A place to put Object methods that pertain to values (e.g., equals 
and hashCode, but not wait and notify)
  - Possibly a place to put top-level methods that do NOT pertain to 
Object (not completely sure what these would be, but its possible we'll 
want some, perhaps boxing and unboxing would be surfaced here)
  - Possibly a type to use as a bound in some contexts (though not clear 
this is needed)
  - Possibly a type to unify what is common between objects and values 
(the current thinking here is something like Objectible / Objectifiable 
/ Objectionable / ObjectionYourHonor, which could be an interface 
implemented by both Object and values.)

I suspect the __ByValue modifier is there to prevent reference classes 
from implementing it, though that can easily be accomplished by other 
means such as compiler restrictions for now (and, since its just a 
placeholder, this is fine); the final modifier does seem suspect.

I think its fair to say that everything about this class (its name, its 
modifiers, whether its a class or an interface, or even whether it 
exists) will eventually change...



On 11/23/2015 3:40 AM, Srikanth wrote:
>
> Hello !
>
> valhalla/src/java.base/share/classes/java/lang/__Value.java
>
> starts with:
>
> package java.lang;
>
> /**
>  * Base class of all value types in prototype implementation.
>  */
> __ByValue final public class __Value {
> // ...
> }
>
> It seems to me that this class (a) should not be final (b) not carry 
> the decoration
> __ByValue. (c) Is better named just Value rather than __Value - this 
> being a type
> name in a name space controlled by JDK. (d) should perhaps be declared 
> abstract.
>
> Also,
>
> Given:
>
> __ByValue final class X {
>     public static void main(String [] args) {
>         System.out.println("Hello");
>     }
> }
>
> at the moment the class file generated by javac[*] encodes an explicit 
> super type:
>
> final value class X extends java.lang.__Value
>
> It would appear the right behavior is to leave the supertype implicit 
> and be
> inferred from the ACC_VALUE flag bit being set.
>
>
> [*] The class file generated cannot be run as of now - since 'Q' in 
> signatures is not digested
> by the VM yet. But using a modified version of javac that emits 'L' 
> even for value types
> I am able to run the program above triggering:
>
> Exception in thread "main" java.lang.VerifyError: Cannot inherit from 
> final class
>
> Srikanth.


From ali.ebrahimi1781 at gmail.com  Mon Nov 23 18:08:28 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 23 Nov 2015 21:38:28 +0330
Subject: java.lang.__Value ??
In-Reply-To: <56534193.1030209@oracle.com>
References: <5652D0FF.6000502@oracle.com>
	<56534193.1030209@oracle.com>
Message-ID: <CAA0cW5BRtTKbr1LJPRpi1YpJPyooMnfGQcNjsuu3ojyuoTWWZw@mail.gmail.com>

Hi,

On Mon, Nov 23, 2015 at 8:10 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> [ adding background ]
>
> The __Value type as it currently stands is simply a placeholder for the
> current round of compiler experiments (hence the deliberately horrible
> name).
>
> In the long run, we need:
>  - A place to put Object methods that pertain to values (e.g., equals and
> hashCode, but not wait and notify)
>  - Possibly a place to put top-level methods that do NOT pertain to Object
> (not completely sure what these would be, but its possible we'll want some,
> perhaps boxing and unboxing would be surfaced here)
>  - Possibly a type to use as a bound in some contexts (though not clear
> this is needed)
>  - Possibly a type to unify what is common between objects and values (the
> current thinking here is something like Objectible / Objectifiable /
> Objectionable / ObjectionYourHonor, which could be an interface implemented
> by both Object and values.)
>
Or Any


-- 

Best Regards,
Ali Ebrahimi

From brian.goetz at oracle.com  Mon Nov 23 18:15:00 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 23 Nov 2015 13:15:00 -0500
Subject: java.lang.__Value ??
In-Reply-To: <CAA0cW5BRtTKbr1LJPRpi1YpJPyooMnfGQcNjsuu3ojyuoTWWZw@mail.gmail.com>
References: <5652D0FF.6000502@oracle.com> <56534193.1030209@oracle.com>
	<CAA0cW5BRtTKbr1LJPRpi1YpJPyooMnfGQcNjsuu3ojyuoTWWZw@mail.gmail.com>
Message-ID: <565357A4.3080207@oracle.com>


> Or Any

As has been discussed earlier, we have deep reservations about that 
name.  In any case, this is effectively a digression into syntax, so can 
we please stop here?  Thanks.

From ali.ebrahimi1781 at gmail.com  Mon Nov 23 18:22:37 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 23 Nov 2015 21:52:37 +0330
Subject: java.lang.__Value ??
In-Reply-To: <565357A4.3080207@oracle.com>
References: <5652D0FF.6000502@oracle.com> <56534193.1030209@oracle.com>
	<CAA0cW5BRtTKbr1LJPRpi1YpJPyooMnfGQcNjsuu3ojyuoTWWZw@mail.gmail.com>
	<565357A4.3080207@oracle.com>
Message-ID: <CAA0cW5Azhb7VwG=b5idw+ptPwF8DS4FVQUOdt1qw04wCVNmpJQ@mail.gmail.com>

Hi,

On Mon, Nov 23, 2015 at 9:45 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>
> Or Any
>>
>
> As has been discussed earlier, we have deep reservations about that name.
> In any case, this is effectively a digression into syntax, so can we please
> stop here?  Thanks.
>
Yes, of course!.


-- 

Best Regards,
Ali Ebrahimi

From pbenedict at apache.org  Mon Nov 23 20:06:53 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 23 Nov 2015 14:06:53 -0600
Subject: java.lang.__Value ??
In-Reply-To: <56534193.1030209@oracle.com>
References: <5652D0FF.6000502@oracle.com>
	<56534193.1030209@oracle.com>
Message-ID: <CABLGb9yn20hOkcJsU5qNdQ46g_-p34y=9GzSoq5+yDtBO-uAsw@mail.gmail.com>

Brian, food for thought from me.

I am not sure what would be the consequences of this, but the so-called
future interface shared between Values and Objects, could also define
universal boxing and unboxing methods:
1) Boxing an object would return itself
2) Unboxing an object ??? / TBD

Even if there are not universal semantics for #2,
Boolean/Byte/Character/Short/Double/Enum/Integer/Long/Short could take
advantage of this to return their intrinsic value.


Cheers,
Paul

On Mon, Nov 23, 2015 at 10:40 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> [ adding background ]
>
> The __Value type as it currently stands is simply a placeholder for the
> current round of compiler experiments (hence the deliberately horrible
> name).
>
> In the long run, we need:
>  - A place to put Object methods that pertain to values (e.g., equals and
> hashCode, but not wait and notify)
>  - Possibly a place to put top-level methods that do NOT pertain to Object
> (not completely sure what these would be, but its possible we'll want some,
> perhaps boxing and unboxing would be surfaced here)
>  - Possibly a type to use as a bound in some contexts (though not clear
> this is needed)
>  - Possibly a type to unify what is common between objects and values (the
> current thinking here is something like Objectible / Objectifiable /
> Objectionable / ObjectionYourHonor, which could be an interface implemented
> by both Object and values.)
>
> I suspect the __ByValue modifier is there to prevent reference classes
> from implementing it, though that can easily be accomplished by other means
> such as compiler restrictions for now (and, since its just a placeholder,
> this is fine); the final modifier does seem suspect.
>
> I think its fair to say that everything about this class (its name, its
> modifiers, whether its a class or an interface, or even whether it exists)
> will eventually change...
>
>
>
>
> On 11/23/2015 3:40 AM, Srikanth wrote:
>
>>
>> Hello !
>>
>> valhalla/src/java.base/share/classes/java/lang/__Value.java
>>
>> starts with:
>>
>> package java.lang;
>>
>> /**
>>  * Base class of all value types in prototype implementation.
>>  */
>> __ByValue final public class __Value {
>> // ...
>> }
>>
>> It seems to me that this class (a) should not be final (b) not carry the
>> decoration
>> __ByValue. (c) Is better named just Value rather than __Value - this
>> being a type
>> name in a name space controlled by JDK. (d) should perhaps be declared
>> abstract.
>>
>> Also,
>>
>> Given:
>>
>> __ByValue final class X {
>>     public static void main(String [] args) {
>>         System.out.println("Hello");
>>     }
>> }
>>
>> at the moment the class file generated by javac[*] encodes an explicit
>> super type:
>>
>> final value class X extends java.lang.__Value
>>
>> It would appear the right behavior is to leave the supertype implicit and
>> be
>> inferred from the ACC_VALUE flag bit being set.
>>
>>
>> [*] The class file generated cannot be run as of now - since 'Q' in
>> signatures is not digested
>> by the VM yet. But using a modified version of javac that emits 'L' even
>> for value types
>> I am able to run the program above triggering:
>>
>> Exception in thread "main" java.lang.VerifyError: Cannot inherit from
>> final class
>>
>> Srikanth.
>>
>
>

From brian.goetz at oracle.com  Tue Nov 24 00:44:35 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 24 Nov 2015 00:44:35 +0000
Subject: hg: valhalla/valhalla/jdk: Incremental progress towards anyfying
	Collections; simple LinkedList examples now working
Message-ID: <201511240044.tAO0iZY1016201@aojmv0008.oracle.com>

Changeset: 4d8621311408
Author:    briangoetz
Date:      2015-11-23 19:44 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4d8621311408

Incremental progress towards anyfying Collections; simple LinkedList examples now working

! src/java.base/share/classes/java/anyutil/AbstractCollection.java
! src/java.base/share/classes/java/anyutil/AbstractList.java
! src/java.base/share/classes/java/anyutil/AbstractSequentialList.java
! src/java.base/share/classes/java/anyutil/Collection.java
! src/java.base/share/classes/java/anyutil/Deque.java
! src/java.base/share/classes/java/anyutil/Iterable.java
! src/java.base/share/classes/java/anyutil/LinkedList.java
! src/java.base/share/classes/java/anyutil/List.java
! src/java.base/share/classes/java/anyutil/Queue.java


From maurizio.cimadamore at oracle.com  Tue Nov 24 00:46:32 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 00:46:32 +0000
Subject: hg: valhalla/valhalla: 76 new changesets
Message-ID: <201511240046.tAO0kXkM016835@aojmv0008.oracle.com>

Changeset: a7ec2278c13d
Author:    ihse
Date:      2015-10-12 11:49 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a7ec2278c13d

8139413: Use --with-x to set X11 root directory
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/lib-x11.m4

Changeset: 81b90ca627de
Author:    lana
Date:      2015-10-15 16:49 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/81b90ca627de

Merge


Changeset: 0bb87e05d83e
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/0bb87e05d83e

Merge


Changeset: 9c467f2d46f0
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/9c467f2d46f0

Added tag jdk9-b88 for changeset 0bb87e05d83e

! .hgtags

Changeset: c867c33f584b
Author:    jlahoda
Date:      2015-10-19 19:13 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/c867c33f584b

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding jdk.jshell module into modules.xml; and listing it among TOOLS_MODULES.
Reviewed-by: alanb, erikj, sundar
Contributed-by: robert.field at oracle.com, jan.lahoda at oracle.com

! make/Images.gmk
! modules.xml

Changeset: a60a0c1bd394
Author:    erikj
Date:      2015-10-20 09:47 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a60a0c1bd394

8139735: Switch compilers in JPRT for windows and linux
Reviewed-by: tbell, ihse

! make/devkit/Tools.gmk
! make/devkit/createWindowsDevkit.sh
! make/jprt.properties

Changeset: 24a3936909e3
Author:    ihse
Date:      2015-10-20 10:39 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/24a3936909e3

8139668: Generate README-build.html from markdown
Reviewed-by: erikj

! README-builds.html
+ README-builds.md
+ common/bin/update-build-readme.sh

Changeset: 257534f191e8
Author:    ihse
Date:      2015-10-20 16:40 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/257534f191e8

8139969: Fix unzip in compare.sh broken by JDK-8136813
Reviewed-by: erikj

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: cb3f10185e63
Author:    erikj
Date:      2015-10-20 17:29 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/cb3f10185e63

8139813: Base heap size on type of boot jdk, not architecture of build machine
Reviewed-by: tbell, ihse

! common/autoconf/boot-jdk.m4
! common/autoconf/generated-configure.sh

Changeset: 8851df90bb66
Author:    erikj
Date:      2015-10-02 17:33 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/8851df90bb66

8138739: Enable devkit on macosx in JPRT (again)
Reviewed-by: ihse

! make/jprt.properties

Changeset: 11c070dc7985
Author:    ddehaven
Date:      2015-10-06 12:51 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/11c070dc7985

Merge


Changeset: efbea01d5b5c
Author:    prr
Date:      2015-10-12 14:44 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/efbea01d5b5c

Merge

- common/autoconf/builddeps.conf.example
- common/autoconf/builddeps.conf.nfs.example
- common/autoconf/builddeps.m4

Changeset: a44eac54cdc3
Author:    prr
Date:      2015-10-20 08:24 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a44eac54cdc3

Merge

! make/jprt.properties

Changeset: 827ea558b8a3
Author:    prr
Date:      2015-10-20 10:33 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/827ea558b8a3

Merge


Changeset: 998803eeed50
Author:    neliasso
Date:      2015-09-18 10:09 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/998803eeed50

8135068: Extract method matchers from CompilerOracle
Summary: Ecapsulate code to enable reuse
Reviewed-by: roland, kvn

! test/lib/sun/hotspot/WhiteBox.java

Changeset: b9acee978e94
Author:    iveresov
Date:      2015-09-25 12:04 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/b9acee978e94

Merge


Changeset: fd80ddb7553f
Author:    amurillo
Date:      2015-10-01 11:52 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/fd80ddb7553f

Merge


Changeset: 0b5d2c8bd667
Author:    amurillo
Date:      2015-10-08 14:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/0b5d2c8bd667

Merge


Changeset: 483de5dbcd96
Author:    dsamersoff
Date:      2015-09-24 20:39 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/483de5dbcd96

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

! test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java
+ test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java

Changeset: 34280222936a
Author:    jwilhelm
Date:      2015-09-28 15:05 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/34280222936a

Merge


Changeset: 9261bce638e3
Author:    jwilhelm
Date:      2015-10-07 00:46 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/9261bce638e3

Merge


Changeset: dec57655571e
Author:    twisti
Date:      2015-10-08 11:31 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/dec57655571e

8136421: JEP 243: Java-Level JVM Compiler Interface
Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett

! .hgignore
! make/CompileJavaModules.gmk
! make/Images.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/common/Modules.gmk
! modules.xml
! test/lib/sun/hotspot/WhiteBox.java
! test/lib/sun/hotspot/code/NMethod.java

Changeset: 82f1be4bd9c3
Author:    dlong
Date:      2015-10-09 02:43 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/82f1be4bd9c3

Merge

- common/autoconf/builddeps.conf.example
- common/autoconf/builddeps.conf.nfs.example
- common/autoconf/builddeps.m4

Changeset: a6e5bdf52315
Author:    dlong
Date:      2015-10-17 15:41 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a6e5bdf52315

Merge


Changeset: 3962780e2eda
Author:    amurillo
Date:      2015-10-19 12:30 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/3962780e2eda

Merge

! make/Images.gmk
! modules.xml

Changeset: 8d498217b215
Author:    amurillo
Date:      2015-10-20 11:56 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/8d498217b215

Merge


Changeset: e3cd4b33d245
Author:    lana
Date:      2015-10-21 18:38 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/e3cd4b33d245

Merge


Changeset: 23d62be63eef
Author:    ihse
Date:      2015-10-22 15:54 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/23d62be63eef

8140277: Configuration out-of-date check should also check closed sources
Reviewed-by: erikj

! make/Init.gmk

Changeset: ae4aba7142a1
Author:    ihse
Date:      2015-10-22 16:41 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/ae4aba7142a1

8140282: Remove test directories on clean-test-*
Reviewed-by: erikj

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/MainSupport.gmk

Changeset: 8d873b9b0031
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/8d873b9b0031

Merge


Changeset: 2396a16033e1
Author:    erikj
Date:      2015-10-27 13:48 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/2396a16033e1

8140484: Vardeps broken when variable value contains '$'
Reviewed-by: tbell

! make/common/MakeBase.gmk
! test/make/TestMakeBase.gmk

Changeset: 8001eddb1672
Author:    erikj
Date:      2015-10-27 17:51 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/8001eddb1672

8140312: Enable new sjavac server only mode in jdk build
Reviewed-by: ihse, tbell

! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/common/JavaCompilation.gmk
! make/common/SetupJavaCompilers.gmk
! make/test/BuildTestLib.gmk

Changeset: cd061b69a817
Author:    jwilhelm
Date:      2015-10-07 00:46 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/cd061b69a817

Merge


Changeset: 08b3c7a80f56
Author:    jprovino
Date:      2015-10-20 11:17 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/08b3c7a80f56

Merge


Changeset: 97134c4eba32
Author:    amurillo
Date:      2015-10-22 16:25 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/97134c4eba32

Merge


Changeset: 895353113f38
Author:    amurillo
Date:      2015-10-27 10:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/895353113f38

Merge


Changeset: cf1dc4c035fb
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/cf1dc4c035fb

Added tag jdk9-b89 for changeset 895353113f38

! .hgtags

Changeset: 3b1bba4161f3
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/3b1bba4161f3

Added tag jdk9-b90 for changeset cf1dc4c035fb

! .hgtags

Changeset: c8470ff83abe
Author:    ihse
Date:      2015-10-29 15:24 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/c8470ff83abe

8140762: Specifying --without-LIB if not needed should not result in warning
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/lib-alsa.m4
! common/autoconf/lib-cups.m4
! common/autoconf/lib-ffi.m4
! common/autoconf/lib-freetype.m4
! common/autoconf/lib-x11.m4

Changeset: f0b8f91a0c6f
Author:    ihse
Date:      2015-10-29 16:30 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/f0b8f91a0c6f

8140661: Rename LDFLAGS_SUFFIX to LIBS
Reviewed-by: erikj

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/common/MakeBase.gmk
! make/common/NativeCompilation.gmk

Changeset: 5f7679c96d7d
Author:    erikj
Date:      2015-10-29 17:11 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/5f7679c96d7d

8140593: Add configure parameter for devkit for the build compiler
Reviewed-by: ihse

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: d7c06f4e28b2
Author:    erikj
Date:      2015-10-29 17:14 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/d7c06f4e28b2

8140591: Add configure argument specifying make executable in JPRT
Reviewed-by: ihse, tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! make/jprt.properties

Changeset: 0cde07d1082a
Author:    lana
Date:      2015-10-29 12:38 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/0cde07d1082a

Merge


Changeset: 122142a18538
Author:    lana
Date:      2015-11-04 13:45 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/122142a18538

Merge


Changeset: fe54fea946e8
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/fe54fea946e8

Added tag jdk9-b91 for changeset 122142a18538

! .hgtags

Changeset: 05228b00bfcf
Author:    jbachorik
Date:      2015-11-02 13:46 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/05228b00bfcf

8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer
Reviewed-by: alanb, dsamersoff, erikj

! make/Images.gmk

Changeset: 5e06ef3a390a
Author:    neliasso
Date:      2015-10-20 18:07 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/5e06ef3a390a

8137167: JEP165: Compiler Control: Implementation task
Summary: Compiler Control JEP
Reviewed-by: roland, twisti, zmajo, simonis

! test/lib/sun/hotspot/WhiteBox.java

Changeset: e81b35d4c8ad
Author:    dlong
Date:      2015-10-27 01:45 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/e81b35d4c8ad

Merge


Changeset: 27f356748627
Author:    amurillo
Date:      2015-10-30 12:03 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/27f356748627

Merge


Changeset: cda1da5fc2dd
Author:    amurillo
Date:      2015-11-02 10:47 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/cda1da5fc2dd

Merge


Changeset: a0c572d90b9d
Author:    erikj
Date:      2015-11-03 16:51 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a0c572d90b9d

8141051: Build test libs -source/-target 9
Reviewed-by: tbell, vlivanov

! make/Main.gmk
! make/test/BuildTestLib.gmk

Changeset: d7f1098c2fc8
Author:    ihse
Date:      2015-11-03 17:48 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/d7f1098c2fc8

8141261: Clean up building of demos
Reviewed-by: erikj, tbell

! make/Images.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/common/JavaCompilation.gmk

Changeset: 426d96f4922f
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/426d96f4922f

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/JrtfsJar.gmk
! make/common/JarArchive.gmk < make/common/JavaCompilation.gmk
+ make/common/JavaCompilation.gmk
! test/make/TestJavaCompilation.gmk

Changeset: d0f163fcd4c8
Author:    erikj
Date:      2015-11-03 18:00 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/d0f163fcd4c8

8141332: Switch macosx devkit in JPRT
Reviewed-by: ihse, tbell

! make/devkit/createMacosxDevkit.sh
! make/jprt.properties

Changeset: 82c695c9b53c
Author:    simonis
Date:      2015-11-04 12:45 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/82c695c9b53c

8141290: AIX: fix build after '8140661: Rename LDFLAGS_SUFFIX to LIBS'
Reviewed-by: ihse

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

Changeset: 1ad0a683c83d
Author:    ihse
Date:      2015-11-05 10:58 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/1ad0a683c83d

8141439: Fix compare.sh -o <otherdir> (broken by JDK-8136813)
Reviewed-by: tbell, erikj

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: a36dc737a448
Author:    ihse
Date:      2015-11-05 15:14 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a36dc737a448

8141414: Deprecate configure source overriding
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! make/common/JavaCompilation.gmk

Changeset: 4ba17e992008
Author:    ihse
Date:      2015-11-05 17:32 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/4ba17e992008

8141543: Propagate --disable-warnings-as-errors to hotspot
Reviewed-by: erikj

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in

Changeset: c26f2d9906cd
Author:    lana
Date:      2015-11-05 13:41 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/c26f2d9906cd

Merge


Changeset: 106c06398f7a
Author:    erikj
Date:      2015-11-05 23:25 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/106c06398f7a

8141574: recent change for 8141543 breaks all builds
Reviewed-by: darcy

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

Changeset: 0f0a47b76da7
Author:    lana
Date:      2015-11-12 10:38 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/0f0a47b76da7

Added tag jdk9-b92 for changeset 106c06398f7a

! .hgtags

Changeset: 58e1d618b84c
Author:    bobv
Date:      2015-10-19 13:21 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/58e1d618b84c

8136556: Add the ability to perform static builds of MacOSX x64 binaries
Reviewed-by: ihse, bdelsart, gadams, lfoltan, rriggs, hseigel, twisti

! common/autoconf/configure.ac
! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
+ make/BuildStatic.gmk
! make/Main.gmk
! make/common/NativeCompilation.gmk

Changeset: 282d3849c90e
Author:    bobv
Date:      2015-10-19 15:47 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/282d3849c90e

Merge


Changeset: f1a26551298e
Author:    bobv
Date:      2015-10-21 16:38 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/f1a26551298e

Merge

! make/Main.gmk

Changeset: 61ca9d7b1d76
Author:    ehelin
Date:      2015-10-21 13:39 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/61ca9d7b1d76

8139256: Add Makefile target to run internal VM tests
Reviewed-by: erikj, ihse

! make/Main.gmk

Changeset: 6bf711eaf861
Author:    ehelin
Date:      2015-10-22 15:28 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/6bf711eaf861

8139271: Add top-level Makefile target to run hotspots jtreg tests
Reviewed-by: ihse, erikj

! make/Main.gmk

Changeset: 1697e1f12275
Author:    jwilhelm
Date:      2015-10-30 00:02 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/1697e1f12275

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: 879da33f4837
Author:    jwilhelm
Date:      2015-11-05 19:31 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/879da33f4837

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! make/common/NativeCompilation.gmk

Changeset: 4982ccf5052b
Author:    twisti
Date:      2015-11-04 07:01 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/4982ccf5052b

8139170: JVMCI refresh
Reviewed-by: kvn

! test/lib/sun/hotspot/code/CodeBlob.java
! test/lib/sun/hotspot/code/NMethod.java

Changeset: 38f26972eae7
Author:    neliasso
Date:      2015-11-06 11:34 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/38f26972eae7

Merge


Changeset: 1b358a99109d
Author:    amurillo
Date:      2015-11-06 11:11 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/1b358a99109d

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/Main.gmk

Changeset: b75a6740986a
Author:    ihse
Date:      2015-11-10 11:41 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/b75a6740986a

8141696: Improve COMPARE_BUILD
Reviewed-by: tbell, erikj

! make/Init.gmk
! make/InitSupport.gmk

Changeset: a8951ccde05f
Author:    chegar
Date:      2015-11-11 11:27 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/a8951ccde05f

8140606: Update library code to use internal Unsafe
Reviewed-by: alanb, mchung, psandoz, weijun

! modules.xml

Changeset: 331fda57dfd3
Author:    lana
Date:      2015-11-12 18:27 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/331fda57dfd3

Merge


Changeset: 430540e2fe98
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/430540e2fe98

Added tag jdk9-b93 for changeset 331fda57dfd3

! .hgtags

Changeset: 7565bb014aad
Author:    mcimadamore
Date:      2015-11-23 11:51 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/7565bb014aad

merge with b93

! common/autoconf/generated-configure.sh
! make/CompileJavaModules.gmk
! make/Images.gmk
! make/common/SetupJavaCompilers.gmk


From maurizio.cimadamore at oracle.com  Tue Nov 24 00:46:59 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 00:46:59 +0000
Subject: hg: valhalla/valhalla/corba: 13 new changesets
Message-ID: <201511240046.tAO0kx0X017015@aojmv0008.oracle.com>

Changeset: 98075de2b055
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/98075de2b055

Added tag jdk9-b88 for changeset 00f48ecbc099

! .hgtags

Changeset: e2c563af9ef4
Author:    msheppar
Date:      2015-06-25 13:48 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/e2c563af9ef4

8076383: Better CORBA exception handling
Reviewed-by: rriggs, coffeys, skoivu, ahgross

! src/jdk.rmic/share/classes/sun/rmi/rmic/iiop/StubGenerator.java

Changeset: dc8238c2c66a
Author:    msheppar
Date:      2015-07-14 16:49 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/dc8238c2c66a

8076392: Improve IIOPInputStream consistency
Reviewed-by: rriggs, coffeys, skoivu, ahgross

! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java

Changeset: a88d571b42b6
Author:    msheppar
Date:      2015-07-14 18:03 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/a88d571b42b6

8076387: Better CORBA value handling
Reviewed-by: rriggs, coffeys, skoivu, ahgross

! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java
! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java

Changeset: ab90c50a6a13
Author:    lana
Date:      2015-10-21 18:38 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/ab90c50a6a13

Merge


Changeset: c847a53b38d2
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/c847a53b38d2

Merge


Changeset: 29cc8228d623
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/29cc8228d623

Added tag jdk9-b89 for changeset c847a53b38d2

! .hgtags

Changeset: 75843e0a9371
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/75843e0a9371

Added tag jdk9-b90 for changeset 29cc8228d623

! .hgtags

Changeset: f7d70caad89a
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/f7d70caad89a

Added tag jdk9-b91 for changeset 75843e0a9371

! .hgtags

Changeset: f82629452836
Author:    lana
Date:      2015-11-12 10:38 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/f82629452836

Added tag jdk9-b92 for changeset f7d70caad89a

! .hgtags

Changeset: e7ddf972e152
Author:    chegar
Date:      2015-11-11 11:31 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/e7ddf972e152

8140606: Update library code to use internal Unsafe
Reviewed-by: alanb, mchung, psandoz, weijun

! src/java.corba/share/classes/com/sun/corba/se/impl/corba/RequestImpl.java
! src/java.corba/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java
! src/java.corba/share/classes/com/sun/corba/se/impl/oa/poa/POAImpl.java
! src/java.corba/share/classes/com/sun/corba/se/impl/oa/poa/POAManagerImpl.java
! src/java.corba/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorImpl_R_USM.java
! src/java.corba/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
! src/java.corba/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java
- src/java.corba/share/classes/com/sun/corba/se/impl/transport/ManagedLocalsThread.java
! src/java.corba/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java
! src/java.corba/share/classes/sun/corba/Bridge.java
! src/java.corba/share/classes/sun/corba/SharedSecrets.java

Changeset: 27e9c8d8091e
Author:    lana
Date:      2015-11-12 18:27 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/27e9c8d8091e

Merge


Changeset: 1f623d855dc7
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/corba/rev/1f623d855dc7

Added tag jdk9-b93 for changeset 27e9c8d8091e

! .hgtags


From maurizio.cimadamore at oracle.com  Tue Nov 24 00:47:28 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 00:47:28 +0000
Subject: hg: valhalla/valhalla/jaxp: 18 new changesets
Message-ID: <201511240047.tAO0lTOk017160@aojmv0008.oracle.com>

Changeset: 27b625ce80f4
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/27b625ce80f4

Added tag jdk9-b88 for changeset 4700fd67e942

! .hgtags

Changeset: 00fa5efc9ace
Author:    joehw
Date:      2015-04-18 00:17 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/00fa5efc9ace

8068842: Better JAXP data handling
Reviewed-by: dfuchs, lancea, hawtin

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltSets.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
- src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/LCount.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/NodeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMUtil.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java
+ src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/PrimeNumberSequenceGenerator.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolHash.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/ElementState.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Utils.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/DOMHelper.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/ElemDesc.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java
! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Keywords.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java
! src/java.xml/share/classes/org/xml/sax/helpers/NamespaceSupport.java

Changeset: 3345330dd03a
Author:    joehw
Date:      2015-05-12 10:02 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/3345330dd03a

8079323: Serialization compatibility for Templates: need to exclude Hashtable from serialization
Reviewed-by: dfuchs, lancea, hawtin

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
+ test/javax/xml/jaxp/unittest/transform/TemplatesTest.java

Changeset: e9fb9655fd36
Author:    joehw
Date:      2015-05-26 10:37 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/e9fb9655fd36

8078427: More supportive home environment
Reviewed-by: dfuchs, lancea, skoivu

! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/TreeWalker.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/TreeWalker.java

Changeset: 5f2ff10c2974
Author:    joehw
Date:      2015-07-07 15:56 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/5f2ff10c2974

8086733: Improve namespace handling
Reviewed-by: dfuchs, lancea, ahgross

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/Entity.java

Changeset: 686f3a3e49ac
Author:    joehw
Date:      2015-07-07 16:57 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/686f3a3e49ac

8130078: Document better processing
Reviewed-by: dfuchs, lancea, ahgross

! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java

Changeset: 198a7fd9ec1f
Author:    lana
Date:      2015-10-21 18:38 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/198a7fd9ec1f

Merge

- src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java

Changeset: 5021da4c9496
Author:    lana
Date:      2015-10-22 11:14 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/5021da4c9496

Merge

- src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java

Changeset: 35f68242b624
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/35f68242b624

Added tag jdk9-b89 for changeset 5021da4c9496

! .hgtags

Changeset: ffaff3d0ad0e
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/ffaff3d0ad0e

Added tag jdk9-b90 for changeset 35f68242b624

! .hgtags

Changeset: c44ed58b7928
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/c44ed58b7928

Added tag jdk9-b91 for changeset ffaff3d0ad0e

! .hgtags

Changeset: d6dcb5df3d6d
Author:    joehw
Date:      2015-10-29 21:53 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/d6dcb5df3d6d

8081248: Implement JEP 268: XML Catalog API
Reviewed-by: lancea, dfuchs

+ src/java.xml/share/classes/javax/xml/catalog/AltCatalog.java
+ src/java.xml/share/classes/javax/xml/catalog/BaseEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/Catalog.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogException.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.properties
+ src/java.xml/share/classes/javax/xml/catalog/CatalogReader.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolver.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java
+ src/java.xml/share/classes/javax/xml/catalog/DelegatePublic.java
+ src/java.xml/share/classes/javax/xml/catalog/DelegateSystem.java
+ src/java.xml/share/classes/javax/xml/catalog/DelegateUri.java
+ src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/NextCatalog.java
+ src/java.xml/share/classes/javax/xml/catalog/Normalizer.java
+ src/java.xml/share/classes/javax/xml/catalog/PublicEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/RewriteSystem.java
+ src/java.xml/share/classes/javax/xml/catalog/RewriteUri.java
+ src/java.xml/share/classes/javax/xml/catalog/SystemEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/SystemSuffix.java
+ src/java.xml/share/classes/javax/xml/catalog/UriEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/UriSuffix.java
+ src/java.xml/share/classes/javax/xml/catalog/Util.java
+ src/java.xml/share/classes/javax/xml/catalog/package.html
+ src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java
! test/javax/xml/jaxp/unittest/TEST.properties
+ test/javax/xml/jaxp/unittest/catalog/CatalogTest.java
+ test/javax/xml/jaxp/unittest/catalog/catalog.xml
+ test/javax/xml/jaxp/unittest/catalog/catalog_invalid.xml
+ test/javax/xml/jaxp/unittest/catalog/delegatepublic.xml
+ test/javax/xml/jaxp/unittest/catalog/delegatesystem.xml
+ test/javax/xml/jaxp/unittest/catalog/files/delegatecatalog.xml
+ test/javax/xml/jaxp/unittest/catalog/files/delegatepublic.dtd
+ test/javax/xml/jaxp/unittest/catalog/files/delegatesystem.dtd
+ test/javax/xml/jaxp/unittest/catalog/files/rewritesystem.dtd
+ test/javax/xml/jaxp/unittest/catalog/files/systemsuffix.dtd
+ test/javax/xml/jaxp/unittest/catalog/public.dtd
+ test/javax/xml/jaxp/unittest/catalog/public.xml
+ test/javax/xml/jaxp/unittest/catalog/rewritesystem.xml
+ test/javax/xml/jaxp/unittest/catalog/rewritesystem1.xml
+ test/javax/xml/jaxp/unittest/catalog/system.dtd
+ test/javax/xml/jaxp/unittest/catalog/system.xml
+ test/javax/xml/jaxp/unittest/catalog/systemsuffix.xml

Changeset: 395cd2b14c1d
Author:    joehw
Date:      2015-10-29 22:12 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/395cd2b14c1d

8077931: Develop tests for XML Catalog API
Reviewed-by: joehw, lancea
Contributed-by: sha.jiang at oracle.com

+ test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java
+ test/javax/xml/jaxp/functional/catalog/DefaultFeaturesTest.java
+ test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java
+ test/javax/xml/jaxp/functional/catalog/DelegatePublicTest.java
+ test/javax/xml/jaxp/functional/catalog/DelegateSystemTest.java
+ test/javax/xml/jaxp/functional/catalog/DelegateUriTest.java
+ test/javax/xml/jaxp/functional/catalog/GroupTest.java
+ test/javax/xml/jaxp/functional/catalog/LoadCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/NextCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/NormalizationTest.java
+ test/javax/xml/jaxp/functional/catalog/PreferFeatureTest.java
+ test/javax/xml/jaxp/functional/catalog/PreferTest.java
+ test/javax/xml/jaxp/functional/catalog/PublicFamilyTest.java
+ test/javax/xml/jaxp/functional/catalog/PublicTest.java
+ test/javax/xml/jaxp/functional/catalog/ResolveFeatureTest.java
+ test/javax/xml/jaxp/functional/catalog/RewriteSystemTest.java
+ test/javax/xml/jaxp/functional/catalog/RewriteUriTest.java
+ test/javax/xml/jaxp/functional/catalog/SpecifyCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/SystemFamilyTest.java
+ test/javax/xml/jaxp/functional/catalog/SystemSuffixTest.java
+ test/javax/xml/jaxp/functional/catalog/SystemTest.java
+ test/javax/xml/jaxp/functional/catalog/UriFamilyTest.java
+ test/javax/xml/jaxp/functional/catalog/UriSuffixTest.java
+ test/javax/xml/jaxp/functional/catalog/UriTest.java
+ test/javax/xml/jaxp/functional/catalog/UrnUnwrappingTest.java
+ test/javax/xml/jaxp/functional/catalog/ValidateCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-itself.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-left.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-right.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/deferFeature.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-alice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-bob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-carl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-alice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-bob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-carl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-alice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-bob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-carl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/group.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/loadCatalogFiles.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-left.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftAlice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftBob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftCarl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-right.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-rightAlice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-rightBob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/normalization.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/prefer.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/preferFeature.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/public.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/publicFamily.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/rewriteSystem.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/rewriteUri.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-api.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-feature.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-sysProps.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/system.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/systemFamily.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/systemSuffix.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/uri.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/uriFamily.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/uriSuffix.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/urnUnwrapping.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-malformed.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-noNamingSpace.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-wrongRoot.xml
+ test/javax/xml/jaxp/isolatedjdk/IsolatedJDK.sh
+ test/javax/xml/jaxp/isolatedjdk/TEST.properties
+ test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.java
+ test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh
+ test/javax/xml/jaxp/isolatedjdk/catalog/catalogFiles/properties.xml
+ test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java
+ test/javax/xml/jaxp/libs/catalog/ResolutionChecker.java

Changeset: fcabfb3c38ac
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/fcabfb3c38ac

Merge


Changeset: f665f69fa8e3
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/f665f69fa8e3

Added tag jdk9-b92 for changeset fcabfb3c38ac

! .hgtags

Changeset: 1528075e9d88
Author:    chegar
Date:      2015-11-11 11:33 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/1528075e9d88

8140606: Update library code to use internal Unsafe
Reviewed-by: alanb, mchung, psandoz, weijun

! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SafeThread.java

Changeset: b9c50c63305c
Author:    lana
Date:      2015-11-12 18:27 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/b9c50c63305c

Merge


Changeset: 510ee559d525
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxp/rev/510ee559d525

Added tag jdk9-b93 for changeset b9c50c63305c

! .hgtags


From maurizio.cimadamore at oracle.com  Tue Nov 24 00:47:59 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 00:47:59 +0000
Subject: hg: valhalla/valhalla/jaxws: 10 new changesets
Message-ID: <201511240048.tAO0m0Er017435@aojmv0008.oracle.com>

Changeset: 3d533243505d
Author:    aefimov
Date:      2015-10-16 19:07 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/3d533243505d

8073519: schemagen does not report errors while generating xsd files
Reviewed-by: dfuchs

! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java

Changeset: f6425fec60ab
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/f6425fec60ab

Merge


Changeset: 2d84c6f4cbba
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/2d84c6f4cbba

Added tag jdk9-b88 for changeset f6425fec60ab

! .hgtags

Changeset: b3e45213d574
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/b3e45213d574

Added tag jdk9-b89 for changeset 2d84c6f4cbba

! .hgtags

Changeset: 3b2a3cb658e4
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/3b2a3cb658e4

Added tag jdk9-b90 for changeset b3e45213d574

! .hgtags

Changeset: 59060592a8fc
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/59060592a8fc

Added tag jdk9-b91 for changeset 3b2a3cb658e4

! .hgtags

Changeset: 63c89fbee619
Author:    mkos
Date:      2015-10-30 10:34 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/63c89fbee619

8139743: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT)
Reviewed-by: lancea

! src/java.xml.bind/share/classes/com/sun/istack/internal/logging/Logger.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/AccessorFactoryImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/DataWriter.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/WellKnownNamespace.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementPropertyInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/package-info.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/DummyPropertyInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeClassInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimePropertyInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/package-info.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/AssociationMap.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/NamespaceContext2.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/C14nXmlOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/NamespaceContextImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XmlVisitor.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/Util.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/CleanUpExecutorFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DecodingException.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/util/XMLStreamReaderToXMLStreamWriter.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/Document.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/ResultFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/XMLWriter.java
! src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java
! src/java.xml.ws/share/classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MessagingException.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentDisposition.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentType.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/HeaderTokenizer.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeBodyPart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeMultipart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePullMultipart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeUtility.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParameterList.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/UniqueValue.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/OutputUtil.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ContextClassloaderLocal.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxReaderBridge.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java
- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java
- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriterEx.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/BindingIDFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/MessageContextFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptor.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/client/package-info.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/db/DatabindingImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/package-info.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/privateutil/ServiceFinder.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/server/package-info.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/db/BindingContext.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/db/BindingContextFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties
- src/java.xml.ws/share/classes/javax/xml/soap/package.html
! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JAnnotationUse.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JClass.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExpr.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExpression.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JJavaName.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/package-info.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ConfigReader.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/Const.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/ModelLoader.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Plugin.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/J2SJAXBModel.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/Mapping.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/S2JJAXBModel.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/SchemaCompiler.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/XJC.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/package.html
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CElementInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CEnumLeafInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/package-info.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/package-info.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/Const.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIAttribute.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIConstructor.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIContent.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIConversion.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIElement.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIEnumeration.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIInterface.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIUserConversion.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/InternalizationLogic.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/Internalizer.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DatatypeLib.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/DefaultClassBinder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIConversion.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIEnum.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIInlineBinaryData.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BISchemaBinding.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXDom.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/EnumMemberMode.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/CustomizationContextChecker.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/XMLSchemaInternalizationLogic.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/DTDEventListener.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/DTDParser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/EntityDecl.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/InputEntity.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/MessageCatalog.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/Resolver.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/XmlChars.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/XmlReader.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/resources/Messages.properties
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/Datatype.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeException.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeLibrary.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeLibraryFactory.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeStreamingValidator.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/ValidationContext.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/StreamingValidatorImpl.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/Grammar.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/GrammarSection.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/IncludedGrammar.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/SchemaBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DChoicePattern.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DDataPattern.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DGrammarPattern.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/nc/NameClass.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/XSSchema.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/XSTerm.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/NGCCRuntime.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/scd/Iterators.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/scd/ParseException.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaTreeTraverser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/parser/XSOMParser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/package-info.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/Options.java

Changeset: fe772cbc64f4
Author:    lana
Date:      2015-11-05 13:43 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/fe772cbc64f4

Merge

- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java
- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java
- src/java.xml.ws/share/classes/javax/xml/soap/package.html
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/package.html

Changeset: 5e94fbbb7032
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/5e94fbbb7032

Added tag jdk9-b92 for changeset fe772cbc64f4

! .hgtags

Changeset: e8d15c61400c
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jaxws/rev/e8d15c61400c

Added tag jdk9-b93 for changeset 5e94fbbb7032

! .hgtags


From maurizio.cimadamore at oracle.com  Tue Nov 24 00:49:06 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 00:49:06 +0000
Subject: hg: valhalla/valhalla/nashorn: 54 new changesets
Message-ID: <201511240049.tAO0n71b017688@aojmv0008.oracle.com>

Changeset: 0cae16c0043d
Author:    attila
Date:      2015-10-12 10:27 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/0cae16c0043d

8139273: Small improvements to DynamicLinker and DynamicLinkerFactory
Reviewed-by: lagergren, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java

Changeset: 494bc9750691
Author:    attila
Date:      2015-10-12 10:28 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/494bc9750691

8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn
Reviewed-by: lagergren, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java

Changeset: 6c6df82265f0
Author:    mhaupt
Date:      2015-10-12 13:36 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/6c6df82265f0

8139266: add JSAdapter example with fallthrough
Reviewed-by: attila, hannesw

+ samples/jsadapter-fallthrough.js

Changeset: 0a640d17732d
Author:    attila
Date:      2015-10-12 13:44 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/0a640d17732d

8139270: Drastically reduce memory footprint of ChainedCallSite
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java

Changeset: 022f7146248d
Author:    attila
Date:      2015-10-12 14:52 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/022f7146248d

8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits
Reviewed-by: mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NoSuchDynamicMethodException.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AccessibleMembersLookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/GuardedInvocationComponent.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java

Changeset: 781e7d23a367
Author:    lana
Date:      2015-10-15 16:50 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/781e7d23a367

Merge


Changeset: a2aa804daac9
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a2aa804daac9

Merge


Changeset: 40bda1a456b9
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/40bda1a456b9

Added tag jdk9-b88 for changeset a2aa804daac9

! .hgtags

Changeset: 04ed602df062
Author:    attila
Date:      2015-10-19 08:23 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/04ed602df062

8139304: Remove elaborate call site descriptor class hierarchy and factory for them. Remove AutoDiscovery, DefaultPrelinkFilter, and BottomGuardingDynamicLinker as they can be inlined into DynamicLinkerFactory. Remove CallerSensitiveDetector as it can be inlined into AbstractJavaLinker. Make ClassMap non-public.
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassLoaderGetterContextProvider.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: 33f2143b60a3
Author:    attila
Date:      2015-10-19 08:30 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/33f2143b60a3

8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java

Changeset: 7dd80d7f47c3
Author:    attila
Date:      2015-10-19 08:39 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/7dd80d7f47c3

8139588: Remove concept of runtime context arguments, call site tokens, and link counts
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: 335632718c1e
Author:    attila
Date:      2015-10-19 08:45 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/335632718c1e

8139590: Improve Dynalink JavaDoc
Reviewed-by: hannesw, lagergren

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodHandleTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodTypeConversionStrategy.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html

Changeset: f93753325c7b
Author:    sundar
Date:      2015-10-19 15:49 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f93753325c7b

8139852: jjs interactive mode fails to work with security manager
Reviewed-by: attila, hannesw

! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/PackagesHelper.java

Changeset: 1faacf3cd85f
Author:    attila
Date:      2015-10-19 18:24 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/1faacf3cd85f

8139756: Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java

Changeset: 17b58e15ad54
Author:    attila
Date:      2015-10-19 22:36 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/17b58e15ad54

8139884: Use privileged blocks when working with class loaders
Reviewed-by: hannesw, mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java

Changeset: dd36e980905b
Author:    attila
Date:      2015-10-20 23:33 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/dd36e980905b

8139761: Improve Dynalink class nomenclature and package organization
Reviewed-by: hannesw, sundar

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocationTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/DefaultInternalObjectFilter.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ChainedCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleRelinkableCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BoundCallableLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java

Changeset: a8d5f14eebcc
Author:    attila
Date:      2015-10-20 23:33 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a8d5f14eebcc

8139887: Reduce visibility of few methods in TypeUtilities and Guards API
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/internal/InternalTypeUtilities.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java

Changeset: c3a5e415a09f
Author:    attila
Date:      2015-10-20 23:34 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c3a5e415a09f

8139888: Improve Dynalink JavaDoc some more
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocationTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodHandleTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodTypeConversionStrategy.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/DefaultInternalObjectFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/package-info.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java

Changeset: 490cafd88488
Author:    attila
Date:      2015-10-20 23:34 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/490cafd88488

8139895: Introduce GuardingDynamicLinkerExporter
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinkerExporter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java

Changeset: e6bb9489faac
Author:    attila
Date:      2015-10-21 10:41 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e6bb9489faac

8139905: Add a convenience AccessControlContext factory
Reviewed-by: hannesw, sundar

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassLoaderGetterContextProvider.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CheckRestrictedPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/internal/AccessControlContextFactory.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessControlContextFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java

Changeset: d35aa8beb997
Author:    attila
Date:      2015-10-21 10:42 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/d35aa8beb997

8139919: Make CallSiteDescriptor a concrete class
Reviewed-by: hannesw, lagergren, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java

Changeset: 7cb19fa78763
Author:    attila
Date:      2015-10-21 19:33 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/7cb19fa78763

8139931: Introduce Operation objects in Dynalink instead of string encoding
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NamedOperation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/Operation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/StandardOperation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionCall.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJavaImporter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BoundCallableLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/InvokeByName.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: b640f10ccd6d
Author:    lana
Date:      2015-10-21 18:39 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/b640f10ccd6d

Merge

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html

Changeset: 77d303d8a943
Author:    attila
Date:      2015-10-22 10:43 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/77d303d8a943

8140273: restore use of CompositeOperation.contains where it is needed
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: 62641244c378
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/62641244c378

Merge

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html

Changeset: bc92163c4e0a
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/bc92163c4e0a

Added tag jdk9-b89 for changeset 62641244c378

! .hgtags

Changeset: f570370bc7b8
Author:    lana
Date:      2015-10-30 10:29 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f570370bc7b8

Added tag jdk9-b90 for changeset bc92163c4e0a

! .hgtags

Changeset: 6d9a3ef84ebf
Author:    mhaupt
Date:      2015-10-28 10:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/6d9a3ef84ebf

8134941: Implement ES6 template literal support
Reviewed-by: attila, hannesw
Contributed-by: andreas.woess at oracle.com

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Lexer.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Token.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/TokenType.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties

Changeset: 1ceda730b9a3
Author:    mhaupt
Date:      2015-10-29 11:37 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/1ceda730b9a3

8140759: add ES6 template literal test
Reviewed-by: hannesw, sundar
Contributed-by: andreas.woess at oracle.com

+ test/script/basic/es6/template-literals.js
+ test/script/basic/es6/template-literals.js.EXPECTED

Changeset: f414ae010340
Author:    lana
Date:      2015-10-29 12:39 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/f414ae010340

Merge


Changeset: fee4d2015e24
Author:    lana
Date:      2015-11-04 13:46 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fee4d2015e24

Merge


Changeset: 09f1d75775ef
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/09f1d75775ef

Added tag jdk9-b91 for changeset fee4d2015e24

! .hgtags

Changeset: c7ef0fb26eff
Author:    attila
Date:      2015-11-02 18:26 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/c7ef0fb26eff

8141144: Move NameCodec to jdk.nashorn.internal space
Reviewed-by: hannesw, sundar

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java

Changeset: ae3c6d8c1fc4
Author:    sundar
Date:      2015-11-03 21:08 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/ae3c6d8c1fc4

8141285: NameCode should pass tests from BytecodeNameTest.java
Reviewed-by: attila, mhaupt

+ samples/find_underscores.js
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java
+ test/src/jdk/nashorn/internal/runtime/linker/test/NameCodecTest.java

Changeset: 1d7341033121
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/1d7341033121

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/BuildNashorn.gmk

Changeset: cc95f96b51d8
Author:    attila
Date:      2015-11-05 12:13 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/cc95f96b51d8

8141425: Improve caching in NashornCallSiteDescriptor
Reviewed-by: hannesw, lagergren

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java

Changeset: a8b20725bcf2
Author:    attila
Date:      2015-11-05 12:15 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a8b20725bcf2

8141524: CompilerTest execution time dominated by Field.setAccessible
Reviewed-by: hannesw, mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ASTWriter.java

Changeset: 0c621f5166c5
Author:    attila
Date:      2015-11-05 15:02 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/0c621f5166c5

8141446: Cache Class.forName for permanently loaded classes
Reviewed-by: hannesw, mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java

Changeset: 34b77a618e98
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/34b77a618e98

Merge

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java

Changeset: 435d7217b35d
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/435d7217b35d

Added tag jdk9-b92 for changeset 34b77a618e98

! .hgtags

Changeset: 752ca580b176
Author:    attila
Date:      2015-11-09 14:03 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/752ca580b176

8141541: Simplify Nashorn's Context class loader handling
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NashornLoader.java

Changeset: e08b29ee795e
Author:    attila
Date:      2015-11-09 14:04 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e08b29ee795e

8141538: Make DynamicLinker specific to a Context in Nashorn
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! test/script/basic/JDK-8011578.js
! test/src/jdk/nashorn/internal/runtime/test/JDK_8078414_Test.java

Changeset: 252538e8c232
Author:    attila
Date:      2015-11-09 15:37 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/252538e8c232

8141550: Introduce a command line option instead of nashorn.unstable.relink.threshold system property
Reviewed-by: hannesw, sundar

! docs/DEVELOPER_README
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Options.properties
! test/script/basic/JDK-8011578.js
! test/script/basic/JDK-8044750.js
! test/script/basic/JDK-8136544.js
! test/script/basic/JDK-8136694.js

Changeset: fe703753f53f
Author:    chegar
Date:      2015-11-11 11:32 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/fe703753f53f

8140606: Update library code to use internal Unsafe
Reviewed-by: alanb, mchung, psandoz, weijun

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java

Changeset: e5ed16b0ae71
Author:    attila
Date:      2015-11-11 14:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e5ed16b0ae71

8142422: Smaller Dynalink API adjustments
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NamedOperation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java

Changeset: 549f06563f1c
Author:    hannesw
Date:      2015-11-11 15:22 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/549f06563f1c

8010803: Number to String conversion functionality overhaul
Reviewed-by: attila, lagergren

! make/build.xml
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeNumber.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
- src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NumberToString.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/Bignum.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/BignumDtoa.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/CachedPowers.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/DiyFp.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/DoubleConversion.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/DtoaBuffer.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/DtoaMode.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/FastDtoa.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/FixedDtoa.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/IeeeDouble.java
! test/script/basic/JDK-8062141.js.EXPECTED
! test/script/basic/NASHORN-389.js
! test/script/basic/NASHORN-389.js.EXPECTED
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumDtoaTest.java
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumTest.java
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/DiyFpTest.java
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/FastDtoaTest.java
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/FixedDtoaTest.java
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/IeeeDoubleTest.java
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/resources/gay-fixed.txt
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/resources/gay-precision.txt
+ test/src/jdk/nashorn/internal/runtime/doubleconv/test/resources/gay-shortest.txt

Changeset: a661018d34b8
Author:    hannesw
Date:      2015-11-11 16:28 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a661018d34b8

8141702: Add support for Symbol property keys
Reviewed-by: attila, sundar

! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Main.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/WeakValueCache.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJavaImporter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeSymbol.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyHashMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyListeners.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SpillProperty.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Symbol.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java
+ test/script/basic/es6.js
! test/script/basic/es6/let.js
+ test/script/basic/es6/symbols.js

Changeset: 1fd94ca4dfcd
Author:    hannesw
Date:      2015-11-11 16:34 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/1fd94ca4dfcd

8141505: floating point parse incorrect on big integer
Reviewed-by: attila, sundar

+ test/script/basic/JDK-8141505.js

Changeset: e1dd1c03e9a9
Author:    hannesw
Date:      2015-11-11 16:35 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e1dd1c03e9a9

8047366: (1000000000000000128).toString() and (1000000000000000128).toFixed() don't evaluate to expected values.
Reviewed-by: attila, sundar

! test/script/basic/JDK-8047369.js

Changeset: a1f59730bfb5
Author:    sundar
Date:      2015-11-12 12:30 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/a1f59730bfb5

8142501: nashorn tests failing after recent changes
Reviewed-by: hannesw

! test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumDtoaTest.java
! test/src/jdk/nashorn/internal/runtime/doubleconv/test/FastDtoaTest.java
! test/src/jdk/nashorn/internal/runtime/doubleconv/test/FixedDtoaTest.java
! test/src/jdk/nashorn/internal/runtime/doubleconv/test/IeeeDoubleTest.java

Changeset: d827dd6e0139
Author:    sundar
Date:      2015-11-12 19:51 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/d827dd6e0139

8142857: Enable all nashorn "api" tests for jtreg test run
Reviewed-by: attila, hannesw, mhaupt

! test/src/jdk/nashorn/api/javaaccess/test/ArrayConversionTest.java
! test/src/jdk/nashorn/api/javaaccess/test/ConsStringTest.java
! test/src/jdk/nashorn/api/scripting/test/InvocableTest.java
! test/src/jdk/nashorn/api/scripting/test/JSONCompatibleTest.java
! test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java
! test/src/jdk/nashorn/api/scripting/test/ScriptEngineSecurityTest.java
! test/src/jdk/nashorn/api/scripting/test/ScriptObjectMirrorTest.java
! test/src/jdk/nashorn/api/tree/test/ParseAPITest.java

Changeset: 2cebe18ffc70
Author:    hannesw
Date:      2015-11-12 19:31 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/2cebe18ffc70

8142864: Raw types warning in WeakValueCache
Reviewed-by: mhaupt, attila

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/WeakValueCache.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java

Changeset: e13533f7bb78
Author:    lana
Date:      2015-11-12 18:32 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/e13533f7bb78

Merge


Changeset: 57e51c71c725
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/nashorn/rev/57e51c71c725

Added tag jdk9-b93 for changeset e13533f7bb78

! .hgtags


From maurizio.cimadamore at oracle.com  Tue Nov 24 01:02:42 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 01:02:42 +0000
Subject: hg: valhalla/valhalla/jdk: 192 new changesets
Message-ID: <201511240102.tAO12nXX020060@aojmv0008.oracle.com>

Changeset: e860e54043fd
Author:    aefimov
Date:      2015-10-10 12:52 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/e860e54043fd

8139107: DateTimeFormatter with Locale.UK throw a NullPointerException when parsing zone
Reviewed-by: naoto

! src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java
! src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java
+ test/sun/util/resources/TimeZone/Bug8139107.java

Changeset: 3bd60f298de4
Author:    chegar
Date:      2015-10-10 17:27 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/3bd60f298de4

8139307: Remove sun.misc.ConditionLock and Lock
Reviewed-by: alanb, lancea, martin, mchung, shade, smarks

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java

Changeset: 7fea29aaa921
Author:    chegar
Date:      2015-10-10 17:30 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7fea29aaa921

8139179: URLStreamHandler* should link to URL ctor that specifies how factories/providers are located
Reviewed-by: alanb

! src/java.base/share/classes/java/net/URLStreamHandlerFactory.java
! src/java.base/share/classes/java/net/spi/URLStreamHandlerProvider.java

Changeset: de8723d4d615
Author:    amlu
Date:      2015-10-12 17:07 +0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/de8723d4d615

8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing
Reviewed-by: chegar

! test/java/rmi/registry/readTest/readTest.sh

Changeset: d1aa33d3720c
Author:    dfuchs
Date:      2015-10-12 20:13 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d1aa33d3720c

8033661: readConfiguration does not cleanly reinitialize the logging system
Summary: two new updateConfiguration methods have been added to LogManager: call updateConfiguration to update a configuration *after* the LogManager is initialized.
Reviewed-by: mchung

! src/java.logging/share/classes/java/util/logging/LogManager.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigWithInputStreamTest.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigurationTest.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java

Changeset: 640d543aea86
Author:    chegar
Date:      2015-10-12 19:14 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/640d543aea86

8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate
Reviewed-by: alanb, jlaskey

! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java

Changeset: fed8b8b53b4b
Author:    plevart
Date:      2015-10-14 00:08 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fed8b8b53b4b

8136893: Improve early java.lang.invoke infrastructure initialization
Reviewed-by: mhaupt, psandoz, redestad, vlivanov

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MemberName.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java

Changeset: 96524d5330db
Author:    dl
Date:      2015-10-13 16:04 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/96524d5330db

8134851: Integrate CompletableFuture with API enhancements
8039378: CompletableFuture: Avoid StackOverflowError for long linear chains
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/CompletionStage.java
! test/java/util/concurrent/CompletableFuture/Basic.java
! test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java
! test/java/util/concurrent/CompletableFuture/ThenComposeExceptionTest.java

Changeset: a0c71499805e
Author:    dl
Date:      2015-10-13 16:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a0c71499805e

8134852: Integrate fork/join with API enhancements
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java
! test/java/util/concurrent/forkjoin/Integrate.java

Changeset: adec55c103f6
Author:    dl
Date:      2015-10-13 16:25 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/adec55c103f6

8134850: Integrate the Flow API
Reviewed-by: martin, psandoz, chegar

+ src/java.base/share/classes/java/util/concurrent/Flow.java
+ src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java

Changeset: 02bb920a3b12
Author:    dl
Date:      2015-10-13 16:35 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/02bb920a3b12

8134855: Bulk integration of java.util.concurrent.locks classes
8051848: ReentrantReadWriteLock.ReadLock fails on unlock by different thread
8049843: Lack of save / restore interrupt mechanism undermines the StampedLock
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/Condition.java
! src/java.base/share/classes/java/util/concurrent/locks/Lock.java
! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java
! src/java.base/share/classes/java/util/concurrent/locks/ReadWriteLock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/Lock/CheckedLockLoops.java
+ test/java/util/concurrent/locks/Lock/LoopHelpers.java
+ test/java/util/concurrent/locks/Lock/Mutex.java
! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java
+ test/java/util/concurrent/locks/LockSupport/ParkLoops.java
! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java
! test/java/util/concurrent/locks/StampedLock/Basic.java

Changeset: 6dd59c01f011
Author:    dl
Date:      2015-10-13 16:45 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6dd59c01f011

8134853: Bulk integration of java.util.concurrent classes
8080939: ForkJoinPool and Phaser deadlock
8044616: Clients of Unsafe.compareAndSwapLong need to beware of using direct stores to the same field
8071638: [JAVADOC] Buggy example in javadoc for afterExecute to access a submitted job's Throwable
8043743: Data missed in java.util.concurrent.LinkedTransferQueue
8054446: Repeated offer and remove on ConcurrentLinkedQueue lead to an OutOfMemoryError
8031374: TEST_BUG: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently
8034208: Cleanup to test/java/util/concurrent/BlockingQueue/Interrupt.java
8035661: Test fix java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java from jsr166 CVS
8062841: ConcurrentHashMap.computeIfAbsent stuck in an endless loop
8073208: javadoc typo in java.util.concurrent.Executor
8073704: FutureTask.isDone returns true when task has not yet completed
8037093: java/util/concurrent/locks/Lock/TimedAcquireLeak.java fails intermittently
8022642: ScheduledThreadPoolExecutor with zero corePoolSize create endlessly threads
8065320: Busy loop in ThreadPoolExecutor.getTask for ScheduledThreadPoolExecutor
8129861: High processor load for ScheduledThreadPoolExecutor with 0 core threads
8051859: ScheduledExecutorService.scheduleWithFixedDelay fails with max delay
7146994: example afterExecute for ScheduledThreadPoolExecutor hangs
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/AbstractQueue.java
! src/java.base/share/classes/java/util/ArrayDeque.java
! src/java.base/share/classes/java/util/ArrayPrefixHelpers.java
! src/java.base/share/classes/java/util/Deque.java
! src/java.base/share/classes/java/util/NavigableMap.java
! src/java.base/share/classes/java/util/NavigableSet.java
! src/java.base/share/classes/java/util/PriorityQueue.java
! src/java.base/share/classes/java/util/Queue.java
! src/java.base/share/classes/java/util/SplittableRandom.java
! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/java.base/share/classes/java/util/concurrent/CountDownLatch.java
! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java
! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java
! src/java.base/share/classes/java/util/concurrent/DelayQueue.java
! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/Executor.java
! src/java.base/share/classes/java/util/concurrent/ExecutorCompletionService.java
! src/java.base/share/classes/java/util/concurrent/ExecutorService.java
! src/java.base/share/classes/java/util/concurrent/Executors.java
! src/java.base/share/classes/java/util/concurrent/Future.java
! src/java.base/share/classes/java/util/concurrent/FutureTask.java
+ src/java.base/share/classes/java/util/concurrent/Helpers.java
! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
! src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
! src/java.base/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/java.base/share/classes/java/util/concurrent/Semaphore.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! src/java.base/share/classes/java/util/concurrent/ThreadFactory.java
! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java
! src/java.base/share/classes/java/util/concurrent/TimeUnit.java
! src/java.base/share/classes/java/util/concurrent/TransferQueue.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/java.base/share/classes/java/util/concurrent/package-info.java
! test/java/util/AbstractList/CheckForComodification.java
! test/java/util/AbstractList/FailFastIterator.java
! test/java/util/Collection/BiggernYours.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collection/testlibrary/CollectionAsserts.java
! test/java/util/Collections/BigBinarySearch.java
! test/java/util/Collections/BinarySearchNullComparator.java
! test/java/util/Collections/CheckedListBash.java
! test/java/util/Collections/CheckedMapBash.java
! test/java/util/Collections/CheckedSetBash.java
! test/java/util/Collections/EmptyCollectionSerialization.java
! test/java/util/Collections/EmptyIterator.java
! test/java/util/Collections/EmptyNavigableMap.java
! test/java/util/Collections/EmptyNavigableSet.java
! test/java/util/Collections/RacingCollections.java
! test/java/util/Collections/ReverseOrder.java
! test/java/util/Collections/RotateEmpty.java
! test/java/util/Collections/T6433170.java
! test/java/util/Collections/WrappedNull.java
! test/java/util/Hashtable/IllegalLoadFactor.java
! test/java/util/Hashtable/ReadObject.java
! test/java/util/IdentityHashMap/ToString.java
! test/java/util/LinkedHashMap/Basic.java
! test/java/util/LinkedHashMap/Cache.java
! test/java/util/LinkedHashSet/Basic.java
! test/java/util/LinkedList/Clone.java
! test/java/util/LinkedList/ComodifiedRemove.java
! test/java/util/List/ListDefaults.java
! test/java/util/Map/Defaults.java
! test/java/util/Map/Get.java
! test/java/util/NavigableMap/LockStep.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
! test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
! test/java/util/TimSort/Sorter.java
! test/java/util/TreeMap/ContainsValue.java
! test/java/util/TreeMap/HeadTailTypeError.java
! test/java/util/TreeMap/SubMap.java
! test/java/util/Vector/ComodifiedRemoveAllElements.java
! test/java/util/Vector/IllegalConstructorArgs.java
! test/java/util/Vector/LastIndexOf.java
! test/java/util/Vector/SyncLastIndexOf.java
! test/java/util/WeakHashMap/GCDuringIteration.java
+ test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.java
+ test/java/util/concurrent/BlockingQueue/DrainToFails.java
! test/java/util/concurrent/BlockingQueue/Interrupt.java
! test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java
! test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java
! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java
! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java
+ test/java/util/concurrent/ConcurrentLinkedQueue/RemoveLeak.java
! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
! test/java/util/concurrent/ConcurrentQueues/GCRetention.java
! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java
! test/java/util/concurrent/CopyOnWriteArrayList/COWSubList.java
! test/java/util/concurrent/CountDownLatch/Basic.java
! test/java/util/concurrent/Exchanger/ExchangeLoops.java
! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java
! test/java/util/concurrent/Executors/AutoShutdown.java
+ test/java/util/concurrent/FutureTask/DoneMeansDone.java
! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java
! test/java/util/concurrent/FutureTask/ExplicitSet.java
! test/java/util/concurrent/FutureTask/NegativeTimeout.java
! test/java/util/concurrent/Phaser/Basic.java
! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java
+ test/java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java
+ test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java
! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java
! test/java/util/concurrent/ThreadPoolExecutor/Custom.java
+ test/java/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java
+ test/java/util/concurrent/ThreadPoolExecutor/ThreadRestarts.java

Changeset: 7dc9726cfa82
Author:    darcy
Date:      2015-10-14 16:17 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7dc9726cfa82

8136799: Port fdlibm cbrt to Java
Reviewed-by: bpb

! make/mapfiles/libjava/mapfile-vers
! src/java.base/share/classes/java/lang/FdLibm.java
! src/java.base/share/classes/java/lang/StrictMath.java
- src/java.base/share/native/libfdlibm/s_cbrt.c
! src/java.base/share/native/libjava/StrictMath.c
! test/java/lang/Math/CubeRootTests.java
! test/java/lang/Math/HypotTests.java
! test/java/lang/Math/IeeeRecommendedTests.java
! test/java/lang/Math/Log1pTests.java
! test/java/lang/StrictMath/CubeRootTests.java
! test/java/lang/StrictMath/FdlibmTranslit.java
! test/java/lang/StrictMath/HypotTests.java

Changeset: d97306dd54cd
Author:    coffeys
Date:      2015-10-15 09:33 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d97306dd54cd

6907252: ZipFileInputStream Not Thread-Safe
Reviewed-by: sherman

! src/java.base/share/classes/java/util/zip/ZStreamRef.java
! src/java.base/share/classes/java/util/zip/ZipFile.java
! src/java.base/share/native/libzip/zip_util.c
+ test/java/util/zip/ZipFile/ZipEntryFreeTest.java

Changeset: 63ddd8dea0ff
Author:    igerasim
Date:      2015-10-15 13:56 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/63ddd8dea0ff

8138938: Clarify javadoc for java.util.Collections.copy()
Reviewed-by: smarks

! src/java.base/share/classes/java/util/Collections.java

Changeset: 91fc3c3826e6
Author:    coffeys
Date:      2015-10-15 14:41 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/91fc3c3826e6

8038502: Deflater.needsInput() should use synchronization
Reviewed-by: chegar

! src/java.base/share/classes/java/util/zip/Deflater.java

Changeset: 34d73930289e
Author:    lana
Date:      2015-10-15 16:51 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/34d73930289e

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java
- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 0440acded788
Author:    aefimov
Date:      2015-10-16 19:05 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0440acded788

8073519: schemagen does not report errors while generating xsd files
Reviewed-by: dfuchs

+ test/javax/xml/bind/jxc/8073519/InputWithError.java
+ test/javax/xml/bind/jxc/8073519/SchemagenErrorReporting.java

Changeset: 6e50b992bef4
Author:    lana
Date:      2015-10-21 15:16 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6e50b992bef4

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java
- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 4a00f31b3995
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4a00f31b3995

Added tag jdk9-b88 for changeset 6e50b992bef4

! .hgtags

Changeset: 2a83d5647e07
Author:    redestad
Date:      2015-10-18 01:43 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2a83d5647e07

8139706: JarFile.getBytes could use InputStream.readNBytes
Reviewed-by: sherman, chegar, alanb

! src/java.base/share/classes/java/util/jar/JarFile.java

Changeset: 9c12c03654a4
Author:    xuelei
Date:      2015-10-19 08:19 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9c12c03654a4

8077806: mismatch comment and code in CipherSuite.java
Reviewed-by: xuelei
Contributed-by: Time Du <tiantian.du at oracle.com>

! src/java.base/share/classes/sun/security/ssl/CipherSuite.java

Changeset: fb7d69e4c624
Author:    jlahoda
Date:      2015-10-19 19:14 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fb7d69e4c624

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding makefile for jshell tool launcher.
Reviewed-by: alanb, erikj, sundar
Contributed-by: robert.field at oracle.com, jan.lahoda at oracle.com

+ make/launcher/Launcher-jdk.jshell.gmk

Changeset: 423df075cf72
Author:    psandoz
Date:      2015-10-19 11:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/423df075cf72

8080418: Add Optional.or()
Reviewed-by: chegar, forax, scolebourne

! src/java.base/share/classes/java/util/Optional.java
! src/java.base/share/classes/java/util/OptionalDouble.java
! src/java.base/share/classes/java/util/OptionalInt.java
! src/java.base/share/classes/java/util/OptionalLong.java
! test/java/util/Optional/Basic.java

Changeset: 9d2d39daa496
Author:    darcy
Date:      2015-10-19 13:48 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9d2d39daa496

8139925: Problem list LFMultiThreadCachingTest.java on windows
Reviewed-by: rriggs, chegar

! test/ProblemList.txt

Changeset: a4bb084549a1
Author:    ascarpino
Date:      2015-10-19 17:26 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a4bb084549a1

8139860: Add ucrypto/TestRSA.java to ProblemList: Message is larger than modulus
Reviewed-by: xuelei

! test/ProblemList.txt

Changeset: 5f032cc89bfd
Author:    ascarpino
Date:      2015-10-19 17:35 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5f032cc89bfd

8133151: Preferred provider configuration for JCE
Reviewed-by: valeriep

! make/gendata/Gendata-java.base.gmk
! make/src/classes/build/tools/makejavasecurity/MakeJavaSecurity.java
! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java
! src/java.base/share/classes/java/security/AlgorithmParameters.java
! src/java.base/share/classes/java/security/KeyFactory.java
! src/java.base/share/classes/java/security/KeyPairGenerator.java
! src/java.base/share/classes/java/security/KeyStore.java
! src/java.base/share/classes/java/security/MessageDigest.java
! src/java.base/share/classes/java/security/Policy.java
! src/java.base/share/classes/java/security/SecureRandom.java
! src/java.base/share/classes/java/security/Signature.java
! src/java.base/share/classes/java/security/cert/CertPathBuilder.java
! src/java.base/share/classes/java/security/cert/CertPathValidator.java
! src/java.base/share/classes/java/security/cert/CertStore.java
! src/java.base/share/classes/java/security/cert/CertificateFactory.java
! src/java.base/share/classes/javax/crypto/Cipher.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java
! src/java.base/share/classes/javax/crypto/KeyAgreement.java
! src/java.base/share/classes/javax/crypto/KeyGenerator.java
! src/java.base/share/classes/javax/crypto/Mac.java
! src/java.base/share/classes/javax/crypto/SecretKeyFactory.java
! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java
! src/java.base/share/classes/javax/net/ssl/SSLContext.java
! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java
! src/java.base/share/classes/javax/security/auth/login/Configuration.java
! src/java.base/share/classes/sun/security/jca/ProviderList.java
! src/java.base/share/conf/security/java.security
! src/java.security.sasl/share/classes/javax/security/sasl/Sasl.java
! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/TransformService.java
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java

Changeset: 37de30468e37
Author:    peytoia
Date:      2015-10-20 19:34 +0900
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/37de30468e37

8072600: Unicode 8 support
Reviewed-by: okutsu

! make/data/characterdata/CharacterData00.java.template
! make/data/characterdata/CharacterData01.java.template
! make/data/unicodedata/PropList.txt
! make/data/unicodedata/Scripts.txt
! make/data/unicodedata/SpecialCasing.txt
! make/data/unicodedata/UnicodeData.txt
! make/data/unicodedata/VERSION
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/sun/text/resources/nfc.icu
! src/java.base/share/classes/sun/text/resources/nfkc.icu
! src/java.base/share/classes/sun/text/resources/nfkc_cf.icu
! src/java.base/share/classes/sun/text/resources/ubidi.icu
! src/java.base/share/classes/sun/text/resources/uprops.icu
! src/java.desktop/share/classes/java/awt/font/NumericShaper.java
! test/java/lang/Character/CheckProp.java
! test/java/lang/Character/CheckScript.java
! test/java/lang/Character/PropList.txt
! test/java/lang/Character/PropertyValueAliases.txt
! test/java/lang/Character/Scripts.txt

Changeset: 86713515444c
Author:    ntv
Date:      2015-10-20 13:10 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/86713515444c

8134928: java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970
Reviewed-by: rriggs, scolebourne

! src/java.base/share/classes/java/time/Instant.java
! test/java/time/tck/java/time/TCKInstant.java

Changeset: 392e83351179
Author:    azvegint
Date:      2015-09-30 13:31 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/392e83351179

8076540: [macosx] NPE due to incorrect threading
Reviewed-by: alexsch, azvegint

+ test/sun/java2d/loops/CopyAreaSpeed.html
+ test/sun/java2d/loops/CopyAreaSpeed.java

Changeset: 1ca9365c8173
Author:    alexsch
Date:      2015-09-30 17:46 +0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/1ca9365c8173

8040322: TextArea.replaceRange() and insert() are broken with setText(null)
Reviewed-by: serb, azvegint
Contributed-by: Ambarish Rapte <ambarish.rapte at oracle.com>

! src/java.desktop/share/classes/java/awt/TextArea.java
+ test/java/awt/TextArea/TextAreaEditing/TextAreaEditing.java

Changeset: 605ab377eed1
Author:    alexsch
Date:      2015-10-02 10:29 +0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/605ab377eed1

8138674: Some platforms may not support showing the user-specified title in a file dialog
Reviewed-by: serb

! src/java.desktop/share/classes/java/awt/FileDialog.java

Changeset: 6fa168f3c0c0
Author:    alexsch
Date:      2015-10-02 17:12 +0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6fa168f3c0c0

8067346: Swing submenu has a changed starting offset
Reviewed-by: serb, alexsch
Contributed-by: Rajeev Chamyal <rajeev.chamyal at oracle.com>

! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/java.desktop/share/classes/sun/awt/OSInfo.java
+ test/javax/swing/JMenu/8067346/bug8067346.java

Changeset: 53700840d4d5
Author:    ssadetsky
Date:      2015-10-05 15:13 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/53700840d4d5

8058959: closed/java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically
Reviewed-by: alexsch, serb

! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java

Changeset: b5125fa7ef4b
Author:    ssadetsky
Date:      2015-10-05 15:29 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b5125fa7ef4b

8079595: Resizing dialog which is JWindow parent makes JVM crash
Reviewed-by: alexsch, serb

! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
+ test/java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java

Changeset: 9b0e9d8ccccf
Author:    psadhukhan
Date:      2015-10-05 15:36 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9b0e9d8ccccf

8132985: Crash in freetypescaler.c due to double free
Reviewed-by: prr, simonis

! src/java.desktop/share/native/libfontmanager/freetypeScaler.c
+ test/java/awt/FontClass/FontDisposer/FontDisposeTest.java

Changeset: eafaa1778c63
Author:    mcherkas
Date:      2015-10-06 10:24 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/eafaa1778c63

8086038: [macosx] No available data flavors when copying from Microsoft Word for Mac
Reviewed-by: serb, alexsch

! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m

Changeset: 95263779ee37
Author:    ddehaven
Date:      2015-10-06 12:51 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/95263779ee37

Merge


Changeset: b89f353e2f9a
Author:    serb
Date:      2015-10-07 19:47 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b89f353e2f9a

4763438: Replace uses of @beaninfo with meta facility in core j2se
Reviewed-by: alexsch, erikj

! make/gensrc/GensrcSwing.gmk
! src/java.desktop/share/classes/java/awt/Button.java
! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/Container.java
! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java
! src/java.desktop/share/classes/java/beans/SimpleBeanInfo.java
! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java
! src/java.desktop/share/classes/javax/swing/AbstractButton.java
! src/java.desktop/share/classes/javax/swing/Box.java
! src/java.desktop/share/classes/javax/swing/ImageIcon.java
! src/java.desktop/share/classes/javax/swing/JApplet.java
! src/java.desktop/share/classes/javax/swing/JButton.java
! src/java.desktop/share/classes/javax/swing/JCheckBox.java
! src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java
! src/java.desktop/share/classes/javax/swing/JColorChooser.java
! src/java.desktop/share/classes/javax/swing/JComboBox.java
! src/java.desktop/share/classes/javax/swing/JComponent.java
! src/java.desktop/share/classes/javax/swing/JDesktopPane.java
! src/java.desktop/share/classes/javax/swing/JDialog.java
! src/java.desktop/share/classes/javax/swing/JEditorPane.java
! src/java.desktop/share/classes/javax/swing/JFileChooser.java
! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java
! src/java.desktop/share/classes/javax/swing/JFrame.java
! src/java.desktop/share/classes/javax/swing/JInternalFrame.java
! src/java.desktop/share/classes/javax/swing/JLabel.java
! src/java.desktop/share/classes/javax/swing/JLayeredPane.java
! src/java.desktop/share/classes/javax/swing/JList.java
! src/java.desktop/share/classes/javax/swing/JMenu.java
! src/java.desktop/share/classes/javax/swing/JMenuBar.java
! src/java.desktop/share/classes/javax/swing/JMenuItem.java
! src/java.desktop/share/classes/javax/swing/JOptionPane.java
! src/java.desktop/share/classes/javax/swing/JPanel.java
! src/java.desktop/share/classes/javax/swing/JPasswordField.java
! src/java.desktop/share/classes/javax/swing/JPopupMenu.java
! src/java.desktop/share/classes/javax/swing/JProgressBar.java
! src/java.desktop/share/classes/javax/swing/JRadioButton.java
! src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java
! src/java.desktop/share/classes/javax/swing/JRootPane.java
! src/java.desktop/share/classes/javax/swing/JScrollBar.java
! src/java.desktop/share/classes/javax/swing/JScrollPane.java
! src/java.desktop/share/classes/javax/swing/JSeparator.java
! src/java.desktop/share/classes/javax/swing/JSlider.java
! src/java.desktop/share/classes/javax/swing/JSpinner.java
! src/java.desktop/share/classes/javax/swing/JSplitPane.java
! src/java.desktop/share/classes/javax/swing/JTabbedPane.java
! src/java.desktop/share/classes/javax/swing/JTable.java
! src/java.desktop/share/classes/javax/swing/JTextArea.java
! src/java.desktop/share/classes/javax/swing/JTextField.java
! src/java.desktop/share/classes/javax/swing/JTextPane.java
! src/java.desktop/share/classes/javax/swing/JToggleButton.java
! src/java.desktop/share/classes/javax/swing/JToolBar.java
! src/java.desktop/share/classes/javax/swing/JToolTip.java
! src/java.desktop/share/classes/javax/swing/JTree.java
! src/java.desktop/share/classes/javax/swing/JViewport.java
! src/java.desktop/share/classes/javax/swing/JWindow.java
! src/java.desktop/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java
! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java
! src/java.desktop/share/classes/javax/swing/table/TableColumn.java
! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java
! src/java.desktop/share/classes/javax/swing/tree/AbstractLayoutCache.java
! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeCellEditor.java
! src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java

Changeset: aafc0a279f95
Author:    psadhukhan
Date:      2015-10-12 15:28 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/aafc0a279f95

8072682: getBounds call on graphics.getDeviceConfiguration() returning cached information
Reviewed-by: serb, flar

! src/java.desktop/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
+ test/java/awt/Graphics2D/DeviceBounds.java

Changeset: bdc017c292af
Author:    serb
Date:      2015-10-12 16:26 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bdc017c292af

8136858: Examine the usage of ThreadGroup.stop() in sun.awt.AppContext
Reviewed-by: alexsch, chegar

! src/java.desktop/share/classes/sun/awt/AppContext.java
+ test/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java
+ test/java/awt/AppContext/ApplicationThreadsStop/java.policy

Changeset: 4b901a05d4ee
Author:    prr
Date:      2015-10-12 14:41 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4b901a05d4ee

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/IOUtils.java
- src/java.base/share/classes/sun/misc/Lock.java

Changeset: daf3f9e17405
Author:    serb
Date:      2015-10-13 14:59 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/daf3f9e17405

8066904: NullPointerException when calling ImageIO.read(InputStream) with corrupt BMP
Reviewed-by: serb, prr
Contributed-by: Jayathirth D V <jayathirth.d.v at oracle.com>

! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
+ test/javax/imageio/plugins/bmp/Bug8066904.java

Changeset: 54a5ff7b22b6
Author:    prr
Date:      2015-10-20 08:24 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/54a5ff7b22b6

Merge

- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 3b02e93e1f9d
Author:    prr
Date:      2015-10-20 10:33 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/3b02e93e1f9d

Merge


Changeset: f4b410327913
Author:    jbachorik
Date:      2015-10-20 20:53 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f4b410327913

8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType
Reviewed-by: dfuchs

! src/java.management/share/classes/sun/management/LazyCompositeData.java
+ test/sun/management/LazyCompositeDataTest.java

Changeset: 4bedcee102c4
Author:    zmajo
Date:      2015-10-05 10:30 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4bedcee102c4

8137173: @HotSpotIntrinsicCandidate is not Oracle-specific
Summary: Change the description of the @HotSpotIntrinsicCandidate annotation.
Reviewed-by: mr, alanb

! src/java.base/share/classes/jdk/internal/HotSpotIntrinsicCandidate.java

Changeset: a1029a7e5efe
Author:    amurillo
Date:      2015-10-08 14:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a1029a7e5efe

Merge


Changeset: a0917b713fda
Author:    dsamersoff
Date:      2015-09-24 20:40 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a0917b713fda

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

+ test/sun/tools/jstack/DeadlockDetectionTest.java

Changeset: 8a9a7b1a3210
Author:    jwilhelm
Date:      2015-09-28 15:05 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8a9a7b1a3210

Merge


Changeset: 703df4322ebb
Author:    dsamersoff
Date:      2015-10-01 10:33 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/703df4322ebb

8133063: Remove BasicLauncherTest from the problem list
Summary: Remove BasicLauncherTest from the problem list
Reviewed-by: jbachorik

! test/ProblemList.txt

Changeset: 593313eedbb0
Author:    jwilhelm
Date:      2015-10-07 00:46 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/593313eedbb0

Merge


Changeset: 12c67db03ee7
Author:    jbachorik
Date:      2015-10-02 18:49 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/12c67db03ee7

8138748: ManagementAgent.status DCMD fails with NPE for JMX configured on command line
Reviewed-by: sspitsyn, dsamersoff, olagneau

! src/java.management/share/classes/sun/management/Agent.java
+ test/sun/management/jmxremote/startstop/JMXStatus1Test.java
+ test/sun/management/jmxremote/startstop/JMXStatus2Test.java
! test/sun/management/jmxremote/startstop/JMXStatusTest.java

Changeset: 3691b2ca322d
Author:    jbachorik
Date:      2015-10-08 09:40 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/3691b2ca322d

8138579: Custom launcher fails to start because of permission problem
Reviewed-by: sspitsyn, dsamersoff

! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java

Changeset: 6bacc922bef7
Author:    jwilhelm
Date:      2015-10-15 13:23 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6bacc922bef7

Merge


Changeset: de4d2d6b5530
Author:    twisti
Date:      2015-10-08 13:32 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/de4d2d6b5530

8136421: JEP 243: Java-Level JVM Compiler Interface
Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett

! make/src/classes/build/tools/module/boot.modules

Changeset: dd09922656aa
Author:    dlong
Date:      2015-10-09 02:43 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/dd09922656aa

Merge


Changeset: 8ed2bee756d6
Author:    redestad
Date:      2015-10-12 15:41 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8ed2bee756d6

8134607: Remove per-compiler performance counters
Reviewed-by: twisti, neliasso

! src/java.management/share/classes/sun/management/CompilerThreadStat.java
! src/java.management/share/classes/sun/management/HotspotCompilation.java
! src/java.management/share/classes/sun/management/HotspotCompilationMBean.java

Changeset: ab8c2b15a29a
Author:    dlong
Date:      2015-10-17 15:41 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/ab8c2b15a29a

Merge


Changeset: eb6219ff2930
Author:    amurillo
Date:      2015-10-19 12:30 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/eb6219ff2930

Merge


Changeset: 92ff2c7d2c50
Author:    amurillo
Date:      2015-10-20 11:56 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/92ff2c7d2c50

Merge

! test/ProblemList.txt

Changeset: 796a4f0d5082
Author:    amurillo
Date:      2015-10-20 17:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/796a4f0d5082

Merge


Changeset: d715a59bca20
Author:    rriggs
Date:      2015-10-21 14:18 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d715a59bca20

8138963: java.lang.Objects new method to default to non-null
Summary: add java.util.Object.nonNullElse and nonNullElseGet
Reviewed-by: dfuchs, jrose, psandoz, smarks, igerasim, chegar

! src/java.base/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: 9a84eb7c34e1
Author:    igerasim
Date:      2015-10-21 22:49 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9a84eb7c34e1

8139373: [TEST_BUG] java/net/MulticastSocket/MultiDead.java failed with timeout
Reviewed-by: chegar

! test/java/net/MulticastSocket/MultiDead.java
! test/lib/testlibrary/jdk/testlibrary/Utils.java

Changeset: 26690783d6fd
Author:    sjiang
Date:      2015-05-07 09:37 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/26690783d6fd

8078440: Safer managed types
Reviewed-by: dfuchs, ahgross

! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java

Changeset: a0e3501ef531
Author:    smarks
Date:      2015-05-08 15:23 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a0e3501ef531

8076413: Better JRMP message handling
Reviewed-by: coffeys, igerasim, ahgross

! src/java.rmi/share/classes/sun/rmi/transport/DGCClient.java

Changeset: e803843a9a36
Author:    serb
Date:      2015-05-23 02:49 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/e803843a9a36

8080541: More direct property handling
Reviewed-by: prr, alexsch

! src/java.desktop/share/classes/java/beans/PropertyDescriptor.java

Changeset: 3975503a71c5
Author:    weijun
Date:      2015-05-24 16:35 +0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/3975503a71c5

8048030: Expectations should be consistent
Reviewed-by: valeriep, mullan, ahgross

! src/java.base/share/classes/javax/security/auth/AuthPermission.java
! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
! src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/java.security.jgss/share/classes/org/ietf/jgss/GSSName.java
! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
! src/java.security.jgss/share/classes/sun/security/krb5/KrbServiceLocator.java
! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java
! src/java.security.jgss/share/classes/sun/security/krb5/Realm.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/SSL.java
! test/sun/security/krb5/name/Constructors.java

Changeset: 662689223d73
Author:    joehw
Date:      2015-05-26 10:39 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/662689223d73

8078427: More supportive home environment
Reviewed-by: dfuchs, lancea, skoivu

! src/java.base/share/conf/security/java.security
! test/java/lang/SecurityManager/CheckPackageAccess.java
! test/java/lang/SecurityManager/RestrictedPackages.java

Changeset: 7cdc4d83ad66
Author:    dtitov
Date:      2015-06-09 11:52 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7cdc4d83ad66

8080246: JNLP app cannot be launched due to deadlock
Reviewed-by: serb, vdrozdov

! src/java.desktop/share/classes/sun/awt/SunToolkit.java

Changeset: 2fed1d855201
Author:    prr
Date:      2015-06-16 14:38 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2fed1d855201

8086092: More palette improvements
Reviewed-by: bae, serb, mschoene

! make/lib/Awt2dLibraries.gmk

Changeset: 323d428e6f0f
Author:    jbachorik
Date:      2015-06-15 12:58 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/323d428e6f0f

8087350: Improve array conversions
Reviewed-by: dfuchs, ahgross

! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java

Changeset: aa49cbb03b23
Author:    ptbrunet
Date:      2015-06-25 15:00 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/aa49cbb03b23

8129611: Accessbridge error handling improvement
Reviewed-by: prr, ahgross, asmotrak
Contributed-by: peter.brunet at oracle.com

! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp
! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.h
! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp

Changeset: 56af9a78c8b7
Author:    smarks
Date:      2015-06-25 16:44 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/56af9a78c8b7

8080688: Service for DGC services
Reviewed-by: skoivu, igerasim, jeff

! src/java.rmi/share/classes/sun/rmi/transport/DGCImpl.java

Changeset: 21be49e17e72
Author:    chegar
Date:      2015-06-29 11:44 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/21be49e17e72

8103671: More objective stream classes
Reviewed-by: rriggs, igerasim

! src/java.base/share/classes/java/io/ObjectStreamClass.java

Changeset: 6b7960246d55
Author:    juh
Date:      2015-06-30 14:22 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6b7960246d55

8081744: Clear out list corner case
Reviewed-by: mullan, rhalade

! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java

Changeset: 5bf77113d49b
Author:    chegar
Date:      2015-07-03 14:40 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5bf77113d49b

8130253: ObjectStreamClass.getFields too restrictive
Reviewed-by: igerasim, skoivu

! src/java.base/share/classes/java/io/ObjectStreamClass.java

Changeset: 76abc44582c5
Author:    michaelm
Date:      2015-07-09 13:23 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/76abc44582c5

8130193: Improve HTTP connections
Reviewed-by: alanb

! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 271003ea3228
Author:    xuelei
Date:      2015-07-13 13:37 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/271003ea3228

8130864: Better server identity handling
Reviewed-by: jnimeh, asmotrak, ahgross

! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java

Changeset: 1fc869ad86a0
Author:    ptbrunet
Date:      2015-07-14 17:06 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/1fc869ad86a0

8130185: More accessible access switch
Reviewed-by: prr, ahgross, asmotrak
Contributed-by: peter.brunet at oracle.com

! src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp

Changeset: 5a5525f17ba1
Author:    xuelei
Date:      2015-07-20 01:45 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5a5525f17ba1

8081760: Better group dynamics
Summary: Allows user to specify custom DH groups. Also reviewed by Alexander Fomin <alexander.fomin at oracle.com>.
Reviewed-by: coffeys, mullan, weijun, jnimeh, ahgross, asmotrak

! src/java.base/share/classes/sun/security/ssl/DHCrypt.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java
! src/java.base/share/conf/security/java.security
! test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java

Changeset: 4a64fcb2f34f
Author:    smarks
Date:      2015-07-20 14:37 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4a64fcb2f34f

8076339: Better handling of remote object invocation
Reviewed-by: asmotrak, igerasim, skoivu

! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java

Changeset: a9dbc8a56c73
Author:    vinnie
Date:      2015-07-24 16:47 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a9dbc8a56c73

8131291: Perfect parameter patterning
Reviewed-by: mullan

! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java

Changeset: a4dd1239afd6
Author:    prr
Date:      2015-07-24 09:44 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a4dd1239afd6

8103675: Better Binary searches
Reviewed-by: srl, serb, mschoene

! src/java.desktop/share/native/libfontmanager/layout/LookupTables.cpp

Changeset: 7b7c731a73d1
Author:    prr
Date:      2015-07-29 11:04 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7b7c731a73d1

8132042: Preserve layout presentation
Reviewed-by: mschoene, srl, serb

! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor.cpp
! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor.h
! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor2.h
! src/java.desktop/share/native/libfontmanager/layout/MorphTables.cpp
! src/java.desktop/share/native/libfontmanager/layout/MorphTables2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SegmentArrayProcessor.cpp
! src/java.desktop/share/native/libfontmanager/layout/SegmentArrayProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SegmentSingleProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SimpleArrayProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SingleTableProcessor.cpp

Changeset: 49760292750d
Author:    bpb
Date:      2015-08-06 10:13 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/49760292750d

8130891: (bf) More direct buffering
Summary: Improve non-byte direct buffering.
Reviewed-by: alanb, jeff, ahgross, robm, rriggs

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template

Changeset: b30f4c331df7
Author:    coffeys
Date:      2015-09-01 18:12 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b30f4c331df7

8133196: HTTPS hostname invalid issue with InetAddress
Reviewed-by: chegar, xuelei

! src/java.base/share/classes/java/net/Inet4Address.java
! src/java.base/share/classes/java/net/InetAddress.java
! src/java.base/share/native/libnet/InetAddress.c
! src/java.base/share/native/libnet/net_util.c
! src/java.base/share/native/libnet/net_util.h
+ test/java/net/InetAddress/getOriginalHostName.java

Changeset: 5dcf71508c1f
Author:    chegar
Date:      2015-09-08 12:40 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5dcf71508c1f

8135043: ObjectStreamClass.getField(String) too restrictive
Reviewed-by: igerasim

! src/java.base/share/classes/java/io/ObjectStreamClass.java
+ test/java/io/ObjectInputStream/TestObjectStreamClass.java

Changeset: a6edbf822256
Author:    chegar
Date:      2015-10-12 10:33 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a6edbf822256

8139352: java/net/InetAddress/getOriginalHostName.java fails to compile
Reviewed-by: mchung, henryjen

! test/java/net/InetAddress/getOriginalHostName.java

Changeset: 35f286a7dd46
Author:    lana
Date:      2015-10-21 18:40 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/35f286a7dd46

Merge


Changeset: f92824cdbaf3
Author:    erikj
Date:      2015-10-22 12:12 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f92824cdbaf3

8140223: fix the build with a toolchain with a linker defaulting to ld --as-needed
Reviewed-by: erikj, ihse
Contributed-by: doko at ubuntu.com

! make/launcher/Launcher-jdk.pack200.gmk
! make/lib/Awt2dLibraries.gmk

Changeset: d93844d0cdd5
Author:    lancea
Date:      2015-10-22 11:36 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d93844d0cdd5

8139056: Add convenience methods to Statement.java
Reviewed-by: joehw, rriggs

! src/java.sql/share/classes/java/sql/Statement.java
+ test/java/sql/testng/test/sql/CallableStatementTests.java
+ test/java/sql/testng/test/sql/PreparedStatementTests.java
+ test/java/sql/testng/test/sql/StatementTests.java
+ test/java/sql/testng/util/StubCallableStatement.java
+ test/java/sql/testng/util/StubPreparedStatement.java
+ test/java/sql/testng/util/StubStatement.java

Changeset: 7ee964fb0608
Author:    jjg
Date:      2015-10-22 10:25 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7ee964fb0608

8140325: Incorrect package.html file
Reviewed-by: darcy

! src/java.base/share/classes/overview-core.html
! src/java.naming/share/classes/javax/naming/spi/package.html

Changeset: eec915634930
Author:    lana
Date:      2015-10-22 11:14 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/eec915634930

Merge


Changeset: eb131795e76e
Author:    naoto
Date:      2015-10-22 21:41 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/eb131795e76e

8136668: Default locale provider adapter incorrectly set to JRE
Reviewed-by: okutsu

! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java

Changeset: 7e55cb303917
Author:    naoto
Date:      2015-10-22 21:44 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7e55cb303917

8134720: Lazy initialization support for currency names in DecimalFormatSymbols
Reviewed-by: okutsu

! src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/java.base/share/classes/java/text/DecimalFormatSymbols.java
! src/java.base/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/java.base/share/classes/sun/util/locale/provider/CalendarProviderImpl.java
! src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/java.base/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

Changeset: 3349db932831
Author:    stuefe
Date:      2015-10-07 15:29 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/3349db932831

8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing
Reviewed-by: goetz, simonis

! src/java.base/unix/native/libnet/ResolverConfigurationImpl.c

Changeset: 0f6c981f1cbf
Author:    mhaupt
Date:      2015-10-27 09:09 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0f6c981f1cbf

8136967: revert all changes applied to obtain information about 8131129
Reviewed-by: sundar

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java
! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

Changeset: 6d88d51aa352
Author:    vtewari
Date:      2015-10-27 10:14 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6d88d51aa352

8068887: java.lang.Throwable could use Collections.emptyList for suppressedException
Summary: java.lang.Throwable could use Collections.emptyList for suppressedException
Reviewed-by: mchung, alanb, shade, redestad

! src/java.base/share/classes/java/lang/Throwable.java

Changeset: 8271f42bae4a
Author:    bchristi
Date:      2015-10-27 09:20 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8271f42bae4a

8138824: java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches()
Reviewed-by: naoto, rriggs

! src/java.base/share/classes/java/lang/String.java
+ test/java/lang/String/EqualsIgnoreCase.java

Changeset: 2cdd66d42587
Author:    jbachorik
Date:      2015-09-23 14:25 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2cdd66d42587

7199353: Define ConstructorProperties annotation type for MXBeans
Reviewed-by: duke

! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
+ src/java.management/share/classes/javax/management/ConstructorProperties.java
! src/java.management/share/classes/javax/management/MXBean.java
! test/javax/management/Introspector/AnnotationSecurityTest.java
! test/javax/management/Introspector/Described.java
! test/javax/management/Introspector/DescribedMX.java
+ test/javax/management/Introspector/LegacyConstructorPropertiesTest.java
! test/javax/management/mxbean/AmbiguousConstructorTest.java
! test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/LeakTest.java
! test/javax/management/mxbean/MXBeanTest.java
! test/javax/management/mxbean/PropertyNamesTest.java
! test/javax/management/mxbean/TigerMXBean.java

Changeset: d68de0bab8ee
Author:    jbachorik
Date:      2015-10-16 06:29 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d68de0bab8ee

8139725: Backout escaped partial fix for JDK-7199353
Reviewed-by: alanb

! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
- src/java.management/share/classes/javax/management/ConstructorProperties.java
! src/java.management/share/classes/javax/management/MXBean.java
! test/javax/management/Introspector/AnnotationSecurityTest.java
! test/javax/management/Introspector/Described.java
! test/javax/management/Introspector/DescribedMX.java
- test/javax/management/Introspector/LegacyConstructorPropertiesTest.java
! test/javax/management/mxbean/AmbiguousConstructorTest.java
! test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/LeakTest.java
! test/javax/management/mxbean/MXBeanTest.java
! test/javax/management/mxbean/PropertyNamesTest.java
! test/javax/management/mxbean/TigerMXBean.java

Changeset: d8a2e5cf4627
Author:    jprovino
Date:      2015-10-20 11:17 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d8a2e5cf4627

Merge


Changeset: de3398e1b429
Author:    amurillo
Date:      2015-10-22 16:25 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/de3398e1b429

Merge


Changeset: f70dcc362579
Author:    amurillo
Date:      2015-10-26 17:19 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f70dcc362579

Merge


Changeset: 0d0a63b32559
Author:    amurillo
Date:      2015-10-27 10:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0d0a63b32559

Merge


Changeset: b433e4dfb830
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b433e4dfb830

Added tag jdk9-b89 for changeset 0d0a63b32559

! .hgtags

Changeset: 19c5d1129851
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/19c5d1129851

Added tag jdk9-b90 for changeset b433e4dfb830

! .hgtags

Changeset: 2e63fa2efdb1
Author:    shurailine
Date:      2015-10-27 20:06 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2e63fa2efdb1

8140336: Add @modules for exported dependencies to jdk_core tests
Reviewed-by: alanb, mchung

! test/java/lang/ProcessHandle/TEST.properties
! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java
! test/java/lang/instrument/AddTransformerTest.java
! test/java/lang/instrument/AppendToBootstrapClassPathTest.java
! test/java/lang/instrument/AppendToClassPathTest.java
! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh
! test/java/lang/instrument/FromShutdownHook.java
! test/java/lang/instrument/GetAllLoadedClassesTest.java
! test/java/lang/instrument/GetInitiatedClassesTest.java
! test/java/lang/instrument/GetObjectSizeTest.java
! test/java/lang/instrument/IsModifiableClassAgent.java
! test/java/lang/instrument/ManifestTest.sh
! test/java/lang/instrument/NativeMethodPrefixAgent.java
! test/java/lang/instrument/NoTransformerAddedTest.java
! test/java/lang/instrument/NullGetObjectSizeTest.java
! test/java/lang/instrument/NullRedefineClassesTests.java
! test/java/lang/instrument/NullTransformerAddTest.java
! test/java/lang/instrument/NullTransformerRemoveTest.java
! test/java/lang/instrument/ParallelTransformerLoader.sh
! test/java/lang/instrument/PremainClass/InheritAgent0010.java
! test/java/lang/instrument/PremainClass/InheritAgent0011.java
! test/java/lang/instrument/PremainClass/InheritAgent0110.java
! test/java/lang/instrument/PremainClass/InheritAgent0111.java
! test/java/lang/instrument/PremainClass/InheritAgent1000.java
! test/java/lang/instrument/PremainClass/InheritAgent1001.java
! test/java/lang/instrument/PremainClass/InheritAgent1010.java
! test/java/lang/instrument/PremainClass/InheritAgent1011.java
! test/java/lang/instrument/PremainClass/InheritAgent1100.java
! test/java/lang/instrument/PremainClass/InheritAgent1101.java
! test/java/lang/instrument/PremainClass/InheritAgent1110.java
! test/java/lang/instrument/PremainClass/InheritAgent1111.java
! test/java/lang/instrument/RedefineBigClass.sh
! test/java/lang/instrument/RedefineClassWithNativeMethod.sh
! test/java/lang/instrument/RedefineClassesDisabledTest.java
! test/java/lang/instrument/RedefineClassesTests.java
! test/java/lang/instrument/RedefineMethodAddInvoke.sh
! test/java/lang/instrument/RedefineMethodDelInvoke.sh
! test/java/lang/instrument/RedefineMethodInBacktrace.sh
! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh
! test/java/lang/instrument/RemoveAbsentTransformerTest.java
! test/java/lang/instrument/RemoveTransformerTest.java
! test/java/lang/instrument/RetransformBigClass.sh
! test/java/lang/instrument/SingleTransformerTest.java
! test/java/lang/instrument/StressGetObjectSizeTest.sh
+ test/java/lang/instrument/TEST.properties
! test/java/lang/instrument/TransformMethodTest.java
! test/java/lang/instrument/TransformerManagementThreadAddTests.java
! test/java/lang/instrument/TransformerManagementThreadRemoveTests.java
! test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh
! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlTest.java
! test/java/lang/invoke/lambda/LambdaAsm.java
! test/java/lang/invoke/lambda/LambdaStackTrace.java
! test/jdk/lambda/TEST.properties
! test/sun/misc/JarIndex/metaInfFilenames/Basic.java
! test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java
! test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java

Changeset: 03453e4301fc
Author:    redestad
Date:      2015-10-28 12:35 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/03453e4301fc

6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory
Reviewed-by: chegar, shade

! src/java.base/share/classes/java/io/ObjectInputStream.java

Changeset: 71e43dd2e0b9
Author:    naoto
Date:      2015-10-26 19:49 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/71e43dd2e0b9

8061287: Update i18n tests to remove references of jre dir
Summary: Updated PropertiesTest.sh to remove references of jre dir.
Reviewed-by: naoto, peytoia
Contributed-by: Rachna Goel <rachna.goel at oracle.com>

! test/java/util/Currency/PropertiesTest.sh

Changeset: d7caf74c48ab
Author:    redestad
Date:      2015-10-28 23:31 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d7caf74c48ab

8066644: Fix deprecation warnings in jdk.zipfs module
Reviewed-by: sherman, shade
Contributed-by: Peter Levart <peter.levart at gmail.com>, Claes Redestad <claes.redestad at gmail.com>

! src/java.base/share/classes/java/util/zip/ZipUtils.java
! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java

Changeset: a0eb148fa9d5
Author:    ihse
Date:      2015-10-29 16:31 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a0eb148fa9d5

8140661: Rename LDFLAGS_SUFFIX to LIBS
Reviewed-by: erikj

! make/CompileDemos.gmk
! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-jdk.accessibility.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/Awt2dLibraries.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-java.management.gmk
! make/lib/Lib-java.prefs.gmk
! make/lib/Lib-java.security.jgss.gmk
! make/lib/Lib-java.smartcardio.gmk
! make/lib/Lib-jdk.accessibility.gmk
! make/lib/Lib-jdk.attach.gmk
! make/lib/Lib-jdk.crypto.ec.gmk
! make/lib/Lib-jdk.crypto.mscapi.gmk
! make/lib/Lib-jdk.crypto.pkcs11.gmk
! make/lib/Lib-jdk.crypto.ucrypto.gmk
! make/lib/Lib-jdk.deploy.osx.gmk
! make/lib/Lib-jdk.internal.le.gmk
! make/lib/Lib-jdk.jdi.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! make/lib/Lib-jdk.management.gmk
! make/lib/Lib-jdk.pack200.gmk
! make/lib/Lib-jdk.sctp.gmk
! make/lib/Lib-jdk.security.auth.gmk
! make/lib/NetworkingLibraries.gmk
! make/lib/NioLibraries.gmk
! make/lib/PlatformLibraries.gmk
! make/lib/SecurityLibraries.gmk
! make/lib/SoundLibraries.gmk

Changeset: bd6ca4cbfa4f
Author:    ascarpino
Date:      2015-10-29 09:09 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bd6ca4cbfa4f

8139859: TestRSA.java: 'message larger than modulus' using SunRsaSign KeyFactory
Reviewed-by: xuelei

! test/ProblemList.txt
! test/com/oracle/security/ucrypto/TestRSA.java

Changeset: 071b08d30f81
Author:    lana
Date:      2015-10-29 12:39 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/071b08d30f81

Merge


Changeset: 97624df5026a
Author:    lana
Date:      2015-11-04 13:46 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/97624df5026a

Merge


Changeset: 13e434966a52
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/13e434966a52

Added tag jdk9-b91 for changeset 97624df5026a

! .hgtags

Changeset: 7f6a82dc978e
Author:    rriggs
Date:      2015-10-30 11:12 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7f6a82dc978e

8139390: Very long classname in jimage causes SIGSEGV
Summary: Correct issues with ImageNativeSubstrate and JImageReadTest
Reviewed-by: mchung

! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/jimage.cpp
! test/jdk/internal/jimage/JImageReadTest.java

Changeset: 8bd5a6e85a2f
Author:    simonis
Date:      2015-11-02 14:57 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8bd5a6e85a2f

8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64
Reviewed-by: wetmore

! test/sun/security/pkcs11/PKCS11Test.java

Changeset: 185252122a39
Author:    naoto
Date:      2015-11-02 08:46 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/185252122a39

8062006: Add a new locale data name "COMPAT" for java.locale.providers system property to reduce ambiguity
Reviewed-by: okutsu

! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! test/java/util/Locale/LocaleProviders.sh

Changeset: 9fef91483af7
Author:    vlivanov
Date:      2015-10-19 17:52 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9fef91483af7

8139881: Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution
Reviewed-by: kvn

! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java

Changeset: 5ff0a80ee6c7
Author:    dlong
Date:      2015-10-27 01:45 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5ff0a80ee6c7

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/IOUtils.java
- src/java.base/share/classes/sun/misc/Lock.java
- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 780bec42fe40
Author:    amurillo
Date:      2015-10-30 12:03 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/780bec42fe40

Merge


Changeset: 5afa5a406c20
Author:    amurillo
Date:      2015-11-02 10:47 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5afa5a406c20

Merge


Changeset: a21b0e82392d
Author:    jbachorik
Date:      2015-09-23 14:25 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a21b0e82392d

8139727: Define ConstructorParameters annotation type for MXBeans
Reviewed-by: alanb, mchung, dfuchs, abuckley, plevart, mr

! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
+ src/java.management/share/classes/javax/management/ConstructorParameters.java
! src/java.management/share/classes/javax/management/MXBean.java
! test/javax/management/Introspector/AnnotationSecurityTest.java
! test/javax/management/Introspector/Described.java
! test/javax/management/Introspector/DescribedMX.java
+ test/javax/management/Introspector/LegacyConstructorPropertiesTest.java
! test/javax/management/mxbean/AmbiguousConstructorTest.java
! test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/LeakTest.java
! test/javax/management/mxbean/MXBeanTest.java
! test/javax/management/mxbean/PropertyNamesTest.java
! test/javax/management/mxbean/TigerMXBean.java

Changeset: 226cd203e48a
Author:    ihse
Date:      2015-11-03 16:15 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/226cd203e48a

6512052: Remove java-rmi.exe and java-rmi.cgi
Reviewed-by: alanb

! make/launcher/Launcher-java.rmi.gmk
- src/java.rmi/unix/bin/java-rmi.cgi.sh

Changeset: 7d07e7aa69ef
Author:    rriggs
Date:      2015-11-03 10:20 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7d07e7aa69ef

8139345: java/lang/ProcessHandle/TreeTest.java test fails with ... Wrong number of children expected [3] but found [2]
Reviewed-by: darcy

! test/java/lang/ProcessHandle/TreeTest.java

Changeset: b6c25628a82d
Author:    ihse
Date:      2015-11-03 17:48 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b6c25628a82d

8141261: Clean up building of demos
Reviewed-by: erikj, tbell

! make/CompileDemos.gmk

Changeset: 30a4e10baf9c
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/30a4e10baf9c

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/gendata/GendataPolicyJars.gmk

Changeset: b66591d98c6b
Author:    serb
Date:      2015-10-18 13:33 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b66591d98c6b

6815345: java.awt.Component.createImage(int width,int height) should remove behavioral optionality
Reviewed-by: prr, ssadetsky

! src/java.desktop/share/classes/java/awt/Component.java
+ test/java/awt/Component/CreateImage/CreateImage.java

Changeset: ddc8bbf88d36
Author:    yan
Date:      2015-10-20 12:42 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/ddc8bbf88d36

8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
Reviewed-by: serb, yan
Contributed-by: Renjith Alexander <renjith.alexander at oracle.com>

+ test/java/awt/EmbeddedFrame/GraphicsConfigTest/GraphicsConfigTest.java
+ test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html
+ test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.java

Changeset: f574643a1c16
Author:    ssadetsky
Date:      2015-10-20 15:42 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f574643a1c16

8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
Reviewed-by: alexsch, serb

! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/ScreenLocation/ScreenLocationTest.java

Changeset: 7993027bcb2f
Author:    ssadetsky
Date:      2015-10-20 15:59 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7993027bcb2f

8022334: After calling frame.toBack() dialog goes to the back on Ubuntu 12.04
Reviewed-by: alexsch, serb

! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/MultiWindowApp/MultiWindowAppTest.java

Changeset: 4d719805b1f1
Author:    aivanov
Date:      2015-10-20 16:55 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4d719805b1f1

8130136: Swing window sometimes fails to repaint partially when it becomes exposed
Reviewed-by: alexp, serb

! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp
! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.h
! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
! src/java.desktop/windows/native/libawt/windows/awt_Component.h

Changeset: b70f060eadf7
Author:    serb
Date:      2015-10-20 22:46 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b70f060eadf7

7182758: BMPMetadata returns invalid PhysicalPixelSpacing
Reviewed-by: serb, vadim
Contributed-by: Jayathirth D V <jayathirth.d.v at oracle.com>

! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
+ test/javax/imageio/plugins/bmp/BMPPixelSpacingTest.java

Changeset: c62b791a8960
Author:    serb
Date:      2015-10-21 18:32 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/c62b791a8960

8138764: In some cases the usage of TreeLock can be replaced by other synchronization
Reviewed-by: alexp, alexsch

! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/Window.java
! src/java.desktop/share/classes/sun/swing/CachedPainter.java
+ test/java/awt/Component/TreeLockDeadlock/TreeLockDeadlock.java

Changeset: 3fdbedd9ff1b
Author:    mcherkas
Date:      2015-10-21 18:58 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/3fdbedd9ff1b

8136763: [macosx] java always returns only one value for "text/uri-list" dataflavor even if several files were copied
Reviewed-by: alexsch, serb

! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
+ test/java/awt/datatransfer/DataFlavor/MacOsXFileAndMultipleFileCopingTest/MacOsXFileAndMultipleFileCopingTest.java
- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: edec0fe63ceb
Author:    prr
Date:      2015-10-21 09:21 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/edec0fe63ceb

8132890: Text overlapping on dot matrix printers.
Reviewed-by: jgodinez, serb

! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java
! test/java/awt/print/PrinterJob/PrintTextTest.java

Changeset: 0746c20f1365
Author:    serb
Date:      2015-10-21 21:28 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0746c20f1365

8041900: [macosx] Java forces the use of discrete GPU
Reviewed-by: ssadetsky, alexsch

! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m

Changeset: deb544c19dec
Author:    sebastian
Date:      2015-10-22 13:46 +0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/deb544c19dec

8139754: Change Boolean constructor use to the use of Boolean factorymethods. For the macosx-port-dev area
Reviewed-by: serb, alexsch

! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java

Changeset: 8bf32c4c2332
Author:    prr
Date:      2015-10-23 10:50 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8bf32c4c2332

Merge

- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 14f8bca09c9b
Author:    ddehaven
Date:      2015-11-03 09:45 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/14f8bca09c9b

Merge

- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: 240ca1b2eb59
Author:    darcy
Date:      2015-11-03 17:41 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/240ca1b2eb59

8141368: Typo in java/lang/Class/IsEnum.java test
Reviewed-by: jjg

! test/java/lang/Class/IsEnum.java

Changeset: 76203cb95f2c
Author:    simonis
Date:      2015-11-04 12:46 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/76203cb95f2c

8141290: AIX: fix build after '8140661: Rename LDFLAGS_SUFFIX to LIBS'
Reviewed-by: ihse

! make/lib/Awt2dLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk

Changeset: 034043795e42
Author:    psandoz
Date:      2015-11-04 16:44 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/034043795e42

8033148: Lexicographic comparators for arrays
Reviewed-by: jrose, chegar, bchristi, mduigou

! src/java.base/share/classes/java/lang/Byte.java
! src/java.base/share/classes/java/lang/Short.java
! src/java.base/share/classes/java/util/Arrays.java
+ test/java/util/Arrays/ArraysEqCmpTest.java

Changeset: ff09a5eddc89
Author:    darcy
Date:      2015-11-04 09:01 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/ff09a5eddc89

8141359: @Deprecated on packages should be clarified
Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/Deprecated.java

Changeset: d3f793857ca3
Author:    darcy
Date:      2015-11-04 11:27 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d3f793857ca3

8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves
Reviewed-by: rriggs

! test/TEST.groups

Changeset: 9ecb10ce62c6
Author:    bpb
Date:      2015-11-04 14:06 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9ecb10ce62c6

8140630: java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build
Summary: Build Bits.c at a lower optimization level on linux-x64.
Reviewed-by: tbell

! make/lib/CoreLibraries.gmk

Changeset: 20ccac7e0705
Author:    ihse
Date:      2015-11-05 10:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/20ccac7e0705

8141444: Clean up building of JDK launchers
Reviewed-by: erikj

! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-java.corba.gmk
! make/launcher/Launcher-java.desktop.gmk
! make/launcher/Launcher-java.rmi.gmk
! make/launcher/Launcher-java.scripting.gmk
! make/launcher/Launcher-java.security.jgss.gmk
! make/launcher/Launcher-jdk.compiler.gmk
! make/launcher/Launcher-jdk.dev.gmk
! make/launcher/Launcher-jdk.hotspot.agent.gmk
! make/launcher/Launcher-jdk.jartool.gmk
! make/launcher/Launcher-jdk.javadoc.gmk
! make/launcher/Launcher-jdk.jcmd.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.jdeps.gmk
! make/launcher/Launcher-jdk.jdi.gmk
! make/launcher/Launcher-jdk.jshell.gmk
! make/launcher/Launcher-jdk.jvmstat.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/Launcher-jdk.policytool.gmk
! make/launcher/Launcher-jdk.rmic.gmk
! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk
! make/launcher/Launcher-jdk.xml.bind.gmk
! make/launcher/Launcher-jdk.xml.ws.gmk
! make/launcher/LauncherCommon.gmk

Changeset: 67d91e7479c1
Author:    lancea
Date:      2015-11-05 10:37 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/67d91e7479c1

8136496: Add Connection.begin/endRequest
Reviewed-by: joehw, rriggs, psandoz

! src/java.sql/share/classes/java/sql/Connection.java
! src/java.sql/share/classes/javax/sql/PooledConnection.java

Changeset: a16ce5acb643
Author:    redestad
Date:      2015-11-05 16:29 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a16ce5acb643

8141539: Avoid calculating string constants in InnerClassLambdaMetaFactory
Reviewed-by: vlivanov

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java

Changeset: 6c9b3dc5bf6b
Author:    redestad
Date:      2015-11-05 16:36 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6c9b3dc5bf6b

8141536: MethodType field offset calculation could be lazy
Reviewed-by: vlivanov

! src/java.base/share/classes/java/lang/invoke/MethodType.java

Changeset: 5b710994aafb
Author:    lancea
Date:      2015-11-05 14:57 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5b710994aafb

8141546: Fix javadoc warnings in Connection due to 8136496
Reviewed-by: alanb

! src/java.sql/share/classes/java/sql/Connection.java

Changeset: 6a5c99506f44
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6a5c99506f44

Merge

- src/java.rmi/unix/bin/java-rmi.cgi.sh
- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: 16fc042acee6
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/16fc042acee6

Added tag jdk9-b92 for changeset 6a5c99506f44

! .hgtags

Changeset: 612588a68bd3
Author:    psandoz
Date:      2015-11-09 09:23 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/612588a68bd3

8141630: Specification of Collections.synchronized* need to state traversal constraints
Reviewed-by: psandoz
Contributed-by: Tagir Valeev <amaembo at gmail.com>

! src/java.base/share/classes/java/util/Collections.java

Changeset: 40cb3080b3dd
Author:    asmotrak
Date:      2015-11-09 13:58 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/40cb3080b3dd

8140649: imageFile should use delete[] with new[]
Reviewed-by: jlaskey

! src/java.base/share/native/libjimage/imageFile.cpp

Changeset: 7ad9bc01099b
Author:    plevart
Date:      2015-11-09 13:44 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7ad9bc01099b

8131129: Attempt to define a duplicate BMH$Species class
Reviewed-by: mhaupt, redestad, vlivanov

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java

Changeset: f3d644bd5380
Author:    omajid
Date:      2015-11-06 17:27 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f3d644bd5380

8139932: Typo in makefile changes for 8043805 [Allow using a system-installed libjpeg]
Reviewed-by: erikj, omajid, prr
Contributed-by: Matthias Klose <doko at ubuntu.com>

! make/lib/Awt2dLibraries.gmk

Changeset: bb286ec75b24
Author:    rriggs
Date:      2015-11-09 11:02 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bb286ec75b24

8138566: (Process) java.lang.Process.allChildren specification clarification
8140213: Process/ProcessHandle.onExit() spec need to be improved
8140250: (process) Process.info description is inaccurate
Summary: rename to descendants() and clarify
Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/Process.java
! src/java.base/share/classes/java/lang/ProcessHandle.java
! src/java.base/share/classes/java/lang/ProcessHandleImpl.java
! test/java/lang/ProcessBuilder/Basic.java
! test/java/lang/ProcessHandle/OnExitTest.java
! test/java/lang/ProcessHandle/PermissionTest.java
! test/java/lang/ProcessHandle/ProcessUtil.java
! test/java/lang/ProcessHandle/TreeTest.java

Changeset: 7e2dc25eef6b
Author:    redestad
Date:      2015-11-09 17:14 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7e2dc25eef6b

8141677: Improve java.lang.invoke.MemberName hashCode implementation
Reviewed-by: vlivanov, psandoz, shade

! src/java.base/share/classes/java/lang/invoke/MemberName.java

Changeset: 6cfb4df38b6d
Author:    redestad
Date:      2015-11-09 17:15 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6cfb4df38b6d

8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches
Reviewed-by: vlivanov, psandoz, shade, plevart

! src/java.base/share/classes/sun/invoke/util/Wrapper.java

Changeset: 5ee9639ba99f
Author:    rhalade
Date:      2015-11-10 01:38 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5ee9639ba99f

8048356: SecureRandom default provider tests
Reviewed-by: wetmore

+ test/java/security/SecureRandom/DefaultProvider.java

Changeset: f3b72beef927
Author:    darcy
Date:      2015-11-09 18:27 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f3b72beef927

8142369: Move TestLocalTime.java to tier 2
Reviewed-by: lancea, sherman

! test/TEST.groups
! test/java/util/zip/TestLocalTime.java

Changeset: 55573c377d64
Author:    bobv
Date:      2015-10-19 13:41 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/55573c377d64

8136556: Add the ability to perform static builds of MacOSX x64 binaries
Reviewed-by: ihse, bdelsart, gadams, lfoltan, rriggs, hseigel, twisti

! make/Import.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.base.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! make/lib/SecurityLibraries.gmk
! make/mapfiles/libnio/mapfile-macosx
! src/demo/share/jvmti/agent_util/agent_util.h
! src/demo/share/jvmti/compiledMethodLoad/compiledMethodLoad.c
! src/demo/share/jvmti/gctest/gctest.c
! src/demo/share/jvmti/heapTracker/heapTracker.c
! src/demo/share/jvmti/heapTracker/heapTracker.h
! src/demo/share/jvmti/heapViewer/heapViewer.c
! src/demo/share/jvmti/minst/minst.c
! src/demo/share/jvmti/minst/minst.h
! src/demo/share/jvmti/mtrace/mtrace.c
! src/demo/share/jvmti/mtrace/mtrace.h
! src/demo/share/jvmti/versionCheck/versionCheck.c
! src/demo/share/jvmti/waiters/Monitor.hpp
! src/demo/share/jvmti/waiters/Thread.cpp
! src/demo/share/jvmti/waiters/waiters.cpp
! src/java.base/macosx/native/libjava/java_props_macosx.c
! src/java.base/macosx/native/libjli/java_md_macosx.c
! src/java.base/share/native/libjava/check_version.c
! src/java.base/share/native/libjava/jio.c
! src/java.base/share/native/libjava/jni_util.h
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libnet/net_util.c
! src/java.base/share/native/libnio/nio_util.c
! src/java.base/share/native/libverify/check_code.c
! src/java.base/share/native/libzip/ZipFile.c
! src/java.base/unix/native/libjava/jlong_md.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
! src/java.desktop/macosx/native/libjawt/jawt.m
! src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.h
! src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
! src/java.desktop/macosx/native/libosxui/AquaLookAndFeel.m
! src/java.desktop/share/native/libfontmanager/sunFont.c
! src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
! src/java.desktop/share/native/libjsound/Platform.c
! src/java.desktop/share/native/libjsound/Utilities.h
! src/java.desktop/share/native/liblcms/LCMS.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageUtils.c
! src/java.desktop/share/native/libsplashscreen/java_awt_SplashScreen.c
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
! src/java.desktop/unix/native/libawt_headless/awt/HeadlessToolkit.c
! src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c
! src/java.desktop/unix/native/libjawt/jawt.c
! src/java.desktop/unix/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c
! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp
! src/java.desktop/windows/native/libjawt/jawt.cpp
! src/java.instrument/share/native/libinstrument/InstrumentationImplNativeMethods.c
! src/java.instrument/share/native/libinstrument/InvocationAdapter.c
! src/java.instrument/share/native/libinstrument/JarFacade.h
! src/java.instrument/share/native/libinstrument/Utilities.h
! src/java.management/share/native/libmanagement/management.c
! src/java.prefs/macosx/native/libprefs/MacOSXPreferencesFile.m
! src/java.prefs/unix/native/libprefs/FileSystemPreferences.c
! src/java.prefs/windows/native/libprefs/WindowsPreferences.c
! src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c
! src/java.security.jgss/share/native/libj2gss/NativeUtil.c
! src/java.security.jgss/share/native/libj2gss/NativeUtil.h
! src/java.security.jgss/windows/native/libw2k_lsa_auth/NativeCreds.c
! src/java.smartcardio/share/native/libj2pcsc/pcsc.c
! src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c
! src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
! src/jdk.attach/solaris/native/libattach/VirtualMachineImpl.c
! src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c
! src/jdk.crypto.ec/share/native/libsunec/ECC_JNI.cpp
! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp
! src/jdk.crypto.pkcs11/share/native/libj2pkcs11/p11_general.c
! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCrypto.c
! src/jdk.deploy.osx/macosx/native/libapplescriptengine/AppleScriptEngine.m
! src/jdk.deploy.osx/macosx/native/libosx/Dispatch.m
! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
! src/jdk.jdwp.agent/share/native/libjdwp/transport.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h
! src/jdk.jdwp.agent/share/native/libjdwp/vm_interface.h
! src/jdk.management/share/native/libmanagement_ext/management_ext.c
! src/jdk.pack200/share/native/common-unpack/utils.cpp
! src/jdk.pack200/share/native/libunpack/jni.cpp
! src/jdk.sctp/unix/native/libsctp/SctpNet.c
! src/jdk.security.auth/unix/native/libjaas/Unix.c
! src/jdk.security.auth/windows/native/libjaas/nt.c

Changeset: 6149969c6e3b
Author:    bobv
Date:      2015-10-19 15:48 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6149969c6e3b

Merge


Changeset: f267778b0caa
Author:    bobv
Date:      2015-10-21 16:39 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f267778b0caa

Merge


Changeset: bd9ffb2bd98f
Author:    chegar
Date:      2015-10-27 14:19 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bd9ffb2bd98f

8139891: Prepare Unsafe for true encapsulation
Reviewed-by: alanb, dholmes, jrose, psandoz, twisti

! src/java.base/share/classes/java/nio/Bits.java
! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template
+ src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/sun/misc/Unsafe.java
! src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java

Changeset: 31d0181ac7af
Author:    bobv
Date:      2015-10-28 10:00 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/31d0181ac7af

8140396: BUILD_LIBJIMAGE missing as a dependency to JAVA_BASE_EXPORT_SYMBOLS_SRC
Reviewed-by: ihse, erikj

! make/lib/Lib-java.base.gmk

Changeset: 5153d05ef8fa
Author:    ctornqvi
Date:      2015-10-28 08:08 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/5153d05ef8fa

8140647: [TESTBUG] Add failing JDK jtreg tests to ProblemList
Reviewed-by: dcubed, rriggs

! test/ProblemList.txt

Changeset: f7dffeae11a0
Author:    ctornqvi
Date:      2015-10-28 19:07 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f7dffeae11a0

Merge


Changeset: 9df3634d9fe2
Author:    jwilhelm
Date:      2015-10-30 00:02 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/9df3634d9fe2

Merge

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! src/java.base/share/native/libnet/net_util.c
! test/ProblemList.txt

Changeset: c62eb4e5d28c
Author:    jwilhelm
Date:      2015-11-05 20:00 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/c62eb4e5d28c

Merge

! make/launcher/LauncherCommon.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! make/lib/SecurityLibraries.gmk
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! test/ProblemList.txt

Changeset: 96bbcecb65eb
Author:    aph
Date:      2015-05-11 15:09 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/96bbcecb65eb

8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049
Summary: nextPutIndex used where nextGetIndex is correct.
Reviewed-by: alanb

! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template

Changeset: 4f6e52f9dc79
Author:    thartmann
Date:      2015-11-03 09:42 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4f6e52f9dc79

8141132: JEP 254: Compact Strings
Summary: Adopt a more space-efficient internal representation for strings.
Reviewed-by: alanb, bdelsart, coleenp, iklam, jiangli, jrose, kevinw, naoto, pliden, roland, smarks, twisti
Contributed-by: Brent Christian <brent.christian at oracle.com>, Vivek Deshpande <vivek.r.deshpande at intel.com>, Tobias Hartmann <tobias.hartmann at oracle.com>, Charlie Hunt <charlie.hunt at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, Roger Riggs <roger.riggs at oracle.com>, Xueming Shen <xueming.shen at oracle.com>, Aleksey Shipilev <aleksey.shipilev at oracle.com>, Sandhya Viswanathan <sandhya.viswanathan at intel.com>

! make/data/charsetmapping/DoubleByte-X.java.template
! make/data/charsetmapping/SingleByte-X.java.template
! make/mapfiles/libjava/mapfile-vers
! make/mapfiles/libjava/reorder-sparc
! make/mapfiles/libjava/reorder-sparcv9
! make/mapfiles/libjava/reorder-x86
! make/src/classes/build/tools/charsetmapping/DBCS.java
! make/src/classes/build/tools/charsetmapping/SBCS.java
! src/java.base/share/classes/java/lang/AbstractStringBuilder.java
! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringBuffer.java
! src/java.base/share/classes/java/lang/StringBuilder.java
! src/java.base/share/classes/java/lang/StringCoding.java
+ src/java.base/share/classes/java/lang/StringDecoderUTF8.java
+ src/java.base/share/classes/java/lang/StringLatin1.java
+ src/java.base/share/classes/java/lang/StringUTF16.java
! src/java.base/share/classes/java/util/Arrays.java
! src/java.base/share/classes/sun/nio/cs/ArrayDecoder.java
! src/java.base/share/classes/sun/nio/cs/ArrayEncoder.java
! src/java.base/share/classes/sun/nio/cs/DoubleByte.java
! src/java.base/share/classes/sun/nio/cs/HKSCS.java
! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
! src/java.base/share/classes/sun/nio/cs/SingleByte.java
+ src/java.base/share/classes/sun/nio/cs/StringUTF16.java
! src/java.base/share/classes/sun/nio/cs/US_ASCII.java
! src/java.base/share/classes/sun/nio/cs/UTF_8.java
! src/java.base/share/native/libjava/String.c
! src/jdk.charsets/share/classes/sun/nio/cs/ext/Big5_Solaris.java.template
! src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM834.java
+ test/java/lang/String/Chars.java
+ test/java/lang/String/CompactString/CharAt.java
+ test/java/lang/String/CompactString/CodePointAt.java
+ test/java/lang/String/CompactString/CodePointBefore.java
+ test/java/lang/String/CompactString/CodePointCount.java
+ test/java/lang/String/CompactString/CompactString.java
+ test/java/lang/String/CompactString/CompareTo.java
+ test/java/lang/String/CompactString/CompareToIgnoreCase.java
+ test/java/lang/String/CompactString/Concat.java
+ test/java/lang/String/CompactString/Contains.java
+ test/java/lang/String/CompactString/EndsWith.java
+ test/java/lang/String/CompactString/Equals.java
+ test/java/lang/String/CompactString/EqualsIgnoreCase.java
+ test/java/lang/String/CompactString/GetChars.java
+ test/java/lang/String/CompactString/IndexOf.java
+ test/java/lang/String/CompactString/Intern.java
+ test/java/lang/String/CompactString/LastIndexOf.java
+ test/java/lang/String/CompactString/Length.java
+ test/java/lang/String/CompactString/Numbers.java
+ test/java/lang/String/CompactString/OffsetByCodePoints.java
+ test/java/lang/String/CompactString/RegionMatches.java
+ test/java/lang/String/CompactString/Replace.java
+ test/java/lang/String/CompactString/SerializationTest.java
+ test/java/lang/String/CompactString/Split.java
+ test/java/lang/String/CompactString/StartsWith.java
+ test/java/lang/String/CompactString/SubString.java
+ test/java/lang/String/CompactString/ToCharArray.java
+ test/java/lang/String/CompactString/ToLowerCase.java
+ test/java/lang/String/CompactString/ToUpperCase.java
+ test/java/lang/String/CompactString/Trim.java
+ test/java/lang/String/CompactString/VMOptionsTest.java
+ test/java/lang/String/CompactString/ValueOf.java
! test/java/lang/String/LiteralReplace.java
! test/java/lang/String/ToLowerCase.java
! test/java/lang/String/ToUpperCase.java
+ test/java/lang/StringBuffer/CompactStringBuffer.java
+ test/java/lang/StringBuffer/CompactStringBufferSerialization.java
! test/java/lang/StringBuffer/Exceptions.java
! test/java/lang/StringBuilder/BuilderForwarding.java
+ test/java/lang/StringBuilder/CompactStringBuilder.java
+ test/java/lang/StringBuilder/CompactStringBuilderSerialization.java
! test/java/lang/StringBuilder/Exceptions.java
+ test/lib/testlibrary/jdk/testlibrary/SerializationUtils.java
! test/sun/nio/cs/TestStringCoding.java
! test/sun/nio/cs/TestStringCodingUTF8.java

Changeset: 01e436a56f3a
Author:    thartmann
Date:      2015-11-05 09:08 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/01e436a56f3a

8141393: [TESTBUG] VMOptionsTest.java fails on ARM
Summary: The test should not assume that CompactStrings is enabled by default on all platforms.
Reviewed-by: roland

! test/java/lang/String/CompactString/VMOptionsTest.java

Changeset: e375214c70c7
Author:    neliasso
Date:      2015-11-06 11:34 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/e375214c70c7

Merge

! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template

Changeset: 6ed36991e804
Author:    amurillo
Date:      2015-11-06 11:11 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6ed36991e804

Merge

! make/launcher/LauncherCommon.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! src/java.base/share/classes/java/util/Arrays.java

Changeset: b31f574254bd
Author:    amurillo
Date:      2015-11-09 20:37 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b31f574254bd

Merge


Changeset: d533cb0187e7
Author:    amlu
Date:      2015-11-10 13:15 +0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d533cb0187e7

8142370: Move java/util/concurrent/Phaser/Basic.java to tier 2
Reviewed-by: darcy, martin

! test/TEST.groups
! test/java/util/concurrent/Phaser/Basic.java

Changeset: bec86ef21b50
Author:    ihse
Date:      2015-11-10 15:00 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/bec86ef21b50

8142383: Use named arguments for SetupCompileProperties in jdk
Reviewed-by: erikj

! make/gensrc/Gensrc-java.base.gmk
! make/gensrc/Gensrc-java.desktop.gmk
! make/gensrc/Gensrc-java.logging.gmk
! make/gensrc/Gensrc-java.management.gmk
! make/gensrc/Gensrc-jdk.dev.gmk
! make/gensrc/Gensrc-jdk.jartool.gmk
! make/gensrc/Gensrc-jdk.jdi.gmk
! make/gensrc/Gensrc-jdk.localedata.gmk
! make/gensrc/GensrcProperties.gmk

Changeset: 4db62628d88c
Author:    ntv
Date:      2015-11-10 14:11 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/4db62628d88c

8066571: UnsupportedTemporalTypeException is thrown not only in the case of unsupported temporal - Java Bug System
Reviewed-by: rriggs, scolebourne

! src/java.base/share/classes/java/time/temporal/IsoFields.java
! test/java/time/test/java/time/temporal/TestIsoWeekFields.java

Changeset: de39f994d657
Author:    ntv
Date:      2015-11-10 14:12 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/de39f994d657

8138664: ZonedDateTime parse error for any date using 'GMT0' ZoneID - Java Bug System
Reviewed-by: rriggs, scolebourne, sherman

! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java

Changeset: fce133de963b
Author:    sebastian
Date:      2015-11-10 21:13 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fce133de963b

8141662: Javadoc fix. Do not suggest to use new Boolean(true).
Summary: Javadoc only fix of 5108778 Too many instances of java.lang.Boolean created in Java application for the java/net library
Reviewed-by: wetmore

! src/java.base/share/classes/java/net/SocketOptions.java

Changeset: f20334e7b5c3
Author:    asmotrak
Date:      2015-11-11 10:42 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f20334e7b5c3

8076359: Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA
Reviewed-by: mullan, ascarpino
Contributed-by: tiantian.du at oracle.com

+ test/sun/security/jca/PreferredProviderNegativeTest.java
+ test/sun/security/jca/PreferredProviderTest.java

Changeset: 98f89fe2b722
Author:    chegar
Date:      2015-11-11 09:19 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/98f89fe2b722

8140606: Update library code to use internal Unsafe
Reviewed-by: alanb, mchung, psandoz, weijun

! make/src/classes/build/tools/x11wrappergen/WrapperGenerator.java
! src/java.base/aix/classes/sun/nio/ch/AixPollPort.java
! src/java.base/linux/classes/sun/nio/ch/EPoll.java
! src/java.base/linux/classes/sun/nio/fs/LinuxDosFileAttributeView.java
! src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java
! src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java
! src/java.base/macosx/classes/sun/nio/ch/KQueue.java
! src/java.base/share/classes/java/io/File.java
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/io/ObjectStreamClass.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/java.base/share/classes/java/math/BigDecimal.java
! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/net/Inet6Address.java
! src/java.base/share/classes/java/net/InetAddress.java
! src/java.base/share/classes/java/net/InetSocketAddress.java
! src/java.base/share/classes/java/nio/MappedByteBuffer.java
! src/java.base/share/classes/java/util/Random.java
! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java
! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/java.base/share/classes/java/util/concurrent/FutureTask.java
! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java
! src/java.base/share/classes/java/util/zip/CRC32C.java
! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java
! src/java.base/share/classes/sun/invoke/anon/AnonymousClassLoader.java
! src/java.base/share/classes/sun/misc/InnocuousThread.java
! src/java.base/share/classes/sun/misc/ManagedLocalsThread.java
! src/java.base/share/classes/sun/nio/ch/NativeObject.java
! src/java.base/share/classes/sun/nio/ch/Util.java
! src/java.base/share/classes/sun/nio/fs/Cancellable.java
! src/java.base/share/classes/sun/nio/fs/NativeBuffer.java
! src/java.base/share/classes/sun/nio/fs/NativeBuffers.java
! src/java.base/share/classes/sun/reflect/AccessorGenerator.java
! src/java.base/share/classes/sun/reflect/ClassDefiner.java
! src/java.base/share/classes/sun/reflect/FieldInfo.java
! src/java.base/share/classes/sun/reflect/MagicAccessorImpl.java
! src/java.base/share/classes/sun/reflect/ReflectionFactory.java
! src/java.base/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
! src/java.base/share/classes/sun/reflect/UnsafeQualifiedFieldAccessorImpl.java
! src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticFieldAccessorImpl.java
! src/java.base/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java
! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java
! src/java.base/solaris/classes/sun/nio/ch/EventPortWrapper.java
! src/java.base/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/java.base/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java
! src/java.base/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/java.base/windows/classes/sun/nio/ch/Iocp.java
! src/java.base/windows/classes/sun/nio/ch/PendingIoCache.java
! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java
! src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/java.base/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java
! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java
! src/java.base/windows/classes/sun/nio/fs/WindowsWatchService.java
! src/java.desktop/share/classes/sun/awt/AWTAccessor.java
! src/java.desktop/share/classes/sun/font/StrikeCache.java
! src/java.desktop/share/classes/sun/java2d/pipe/RenderBuffer.java
! src/java.desktop/share/classes/sun/swing/SwingAccessor.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDConstants.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/Native.java
! src/java.desktop/unix/classes/sun/awt/X11/UnsafeXDisposerRecord.java
! src/java.desktop/unix/classes/sun/awt/X11/WindowPropertyGetter.java
! src/java.desktop/unix/classes/sun/awt/X11/XAtom.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDropTargetContextPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedHelper.java
! src/java.desktop/unix/classes/sun/awt/X11/XKeysym.java
! src/java.desktop/unix/classes/sun/awt/X11/XQueryTree.java
! src/java.desktop/unix/classes/sun/awt/X11/XTranslateCoordinates.java
! src/java.desktop/unix/classes/sun/awt/X11/XWM.java
! src/java.desktop/unix/classes/sun/awt/X11/XlibWrapper.java
! src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h
! src/java.management/share/classes/sun/management/BaseOperatingSystemImpl.java
! src/java.management/share/classes/sun/management/ManagementFactoryHelper.java
! src/java.security.jgss/share/classes/sun/security/krb5/KerberosSecrets.java
! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java

Changeset: eaf66e3285c8
Author:    rriggs
Date:      2015-11-11 22:38 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/eaf66e3285c8

8141652: Rename methods Objects.nonNullElse* to requireNonNullElse*
Summary: And some usages of replacing expr != null ? expr : otherexpr
Reviewed-by: jrose, chegar

! src/java.base/share/classes/java/net/InetAddress.java
! src/java.base/share/classes/java/net/URLConnection.java
! src/java.base/share/classes/java/nio/charset/Charset.java
! src/java.base/share/classes/java/security/SecureRandom.java
! src/java.base/share/classes/java/time/ZoneId.java
! src/java.base/share/classes/java/time/chrono/Chronology.java
! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/java.base/share/classes/java/time/format/DateTimePrintContext.java
! src/java.base/share/classes/java/util/Formatter.java
! src/java.base/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: 2a49e593ad60
Author:    robm
Date:      2015-11-12 13:37 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2a49e593ad60

8132455: com/sun/jndi/ldap/LdapTimeoutTest.java fails at handleNamingException
Reviewed-by: vinnie

! test/com/sun/jndi/ldap/LdapTimeoutTest.java

Changeset: 2f12392d0dde
Author:    lana
Date:      2015-11-12 18:31 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2f12392d0dde

Merge


Changeset: 906c3a20e42c
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/906c3a20e42c

Added tag jdk9-b93 for changeset 2f12392d0dde

! .hgtags

Changeset: f99e5d6f1bab
Author:    mcimadamore
Date:      2015-11-23 11:54 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f99e5d6f1bab

merge with b93

! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java
+ src/java.base/share/classes/jdk/internal/misc/Unsafe.java
- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java
! src/java.base/share/classes/sun/misc/Unsafe.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java
- src/java.base/share/native/libfdlibm/s_cbrt.c
+ src/java.management/share/classes/javax/management/ConstructorParameters.java
- src/java.rmi/unix/bin/java-rmi.cgi.sh
! test/TEST.groups
- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: 0ec6c54a8c68
Author:    mcimadamore
Date:      2015-11-24 00:52 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0ec6c54a8c68

merge



From maurizio.cimadamore at oracle.com  Tue Nov 24 01:05:13 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 01:05:13 +0000
Subject: hg: valhalla/valhalla/langtools: 47 new changesets
Message-ID: <201511240105.tAO15EG2020582@aojmv0008.oracle.com>

Changeset: 79e637c1e083
Author:    mcimadamore
Date:      2015-10-12 12:24 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/79e637c1e083

8138840: NPE when compiling bitwise operations with illegal operand types
8139243: compiler crashes with exception on sum operation of String var and void method call result
8139249: Compiler crashes on unary bitwise complement with non-integral operand
Summary: Certain binary operator checks are accepting more operands than required.
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Operators.java
+ test/tools/javac/8138840/T8138840.java
+ test/tools/javac/8138840/T8138840.out
+ test/tools/javac/8138840/T8139243.java
+ test/tools/javac/8138840/T8139243.out
+ test/tools/javac/8138840/T8139249.java
+ test/tools/javac/8138840/T8139249.out

Changeset: 700677b16a97
Author:    sadayapalam
Date:      2015-10-12 19:43 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/700677b16a97

8139245: compiler crashes with exception on int:new method reference and generic method inference
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.java
+ test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.out

Changeset: 814a0cab8c90
Author:    sadayapalam
Date:      2015-10-13 09:48 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/814a0cab8c90

8000316: Huge performance bottleneck in com.sun.tools.javac.comp.Check.localClassName
Summary: Speed up Check.localClassName by avoiding generating names known to be in use already
Reviewed-by: mcimadamore, jlahoda, sadayapalam
Contributed-by: dmitry.chuyko at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/T8000316/T8000316.java

Changeset: 575ea88f69a5
Author:    chegar
Date:      2015-10-13 09:02 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/575ea88f69a5

8139371: Three langtools test failures after the removal of sun.misc.Lock
Reviewed-by: jjg, mchung

! test/tools/javac/proprietary/WarnClass.java
! test/tools/javac/proprietary/WarnClass.out
! test/tools/javac/warnings/6594914/T6594914b.java
! test/tools/javac/warnings/6594914/T6594914b.out
! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/m/Gee.java

Changeset: 126e5c6abd1d
Author:    lana
Date:      2015-10-15 16:50 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/126e5c6abd1d

Merge


Changeset: ac57d80b205d
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ac57d80b205d

Merge


Changeset: 4789df418bc3
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4789df418bc3

Added tag jdk9-b88 for changeset ac57d80b205d

! .hgtags

Changeset: 23f76aadbb36
Author:    ksrini
Date:      2015-09-11 16:34 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/23f76aadbb36

8078320: Improve DocTrees parsing.
Reviewed-by: jjg, jlahoda

! src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/doclint/HtmlTag.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/tools/javac/doctree/DocCommentTester.java
! test/tools/javac/doctree/ElementTest.java
! test/tools/javac/doctree/FirstSentenceTest.java
+ test/tools/javac/doctree/InPreTest.java
! test/tools/javac/doctree/TagTest.java

Changeset: 777c5a760a84
Author:    jlahoda
Date:      2015-10-19 12:41 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/777c5a760a84

8139751: Javac crash with -XDallowStringFolding=false
Summary: When string folding is disabled, need to keep the original expression.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/tools/javac/parser/StringFoldingTest.java

Changeset: 15bdc18525ff
Author:    jlahoda
Date:      2015-10-19 19:15 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/15bdc18525ff

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding the implementation of the jshell (read-eval-print-loop) tool.
Reviewed-by: briangoetz, mcimadamore, psandoz, forax
Contributed-by: robert.field at oracle.com, bitterfoxc at gmail.com, jan.lahoda at oracle.com

! make/build.properties
! make/build.xml
+ make/gensrc/Gensrc-jdk.jshell.gmk
! make/intellij/langtools.iml
! make/intellij/workspace.xml
! make/launcher.sh-template
! make/netbeans/langtools/build.xml
! make/netbeans/langtools/nbproject/project.xml
+ make/tools/anttasks/DumpClassesTask.java
! make/tools/anttasks/SelectToolTask.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteClassLoader.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteCodes.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteResolutionException.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditPad.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditingHistory.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/version.properties-template
+ src/jdk.jshell/share/classes/jdk/jshell/ClassTracker.java
+ src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java
+ src/jdk.jshell/share/classes/jdk/jshell/DeclarationSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/Diag.java
+ src/jdk.jshell/share/classes/jdk/jshell/DiagList.java
+ src/jdk.jshell/share/classes/jdk/jshell/ErroneousSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/Eval.java
+ src/jdk.jshell/share/classes/jdk/jshell/EvalException.java
+ src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java
+ src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/GeneralWrap.java
+ src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDIConnection.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDIEnv.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDIEventHandler.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDINotConnectedException.java
+ src/jdk.jshell/share/classes/jdk/jshell/JShell.java
+ src/jdk.jshell/share/classes/jdk/jshell/Key.java
+ src/jdk.jshell/share/classes/jdk/jshell/KeyMap.java
+ src/jdk.jshell/share/classes/jdk/jshell/MaskCommentsAndModifiers.java
+ src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
+ src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/OuterWrap.java
+ src/jdk.jshell/share/classes/jdk/jshell/PersistentSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java
+ src/jdk.jshell/share/classes/jdk/jshell/ReplParserFactory.java
+ src/jdk.jshell/share/classes/jdk/jshell/ReplResolve.java
+ src/jdk.jshell/share/classes/jdk/jshell/Snippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/SnippetEvent.java
+ src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java
+ src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
+ src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
+ src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
+ src/jdk.jshell/share/classes/jdk/jshell/TreeDependencyScanner.java
+ src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java
+ src/jdk.jshell/share/classes/jdk/jshell/TypeDeclSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java
+ src/jdk.jshell/share/classes/jdk/jshell/Unit.java
+ src/jdk.jshell/share/classes/jdk/jshell/UnresolvedReferenceException.java
+ src/jdk.jshell/share/classes/jdk/jshell/Util.java
+ src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/Wrap.java
+ src/jdk.jshell/share/classes/jdk/jshell/package-info.java
+ test/jdk/jshell/AnalysisTest.java
+ test/jdk/jshell/ClassMembersTest.java
+ test/jdk/jshell/ClassPathTest.java
+ test/jdk/jshell/ClassesTest.java
+ test/jdk/jshell/CommandCompletionTest.java
+ test/jdk/jshell/Compiler.java
+ test/jdk/jshell/CompletenessStressTest.java
+ test/jdk/jshell/CompletenessTest.java
+ test/jdk/jshell/CompletionSuggestionTest.java
+ test/jdk/jshell/CustomEditor.java
+ test/jdk/jshell/DropTest.java
+ test/jdk/jshell/EditorPadTest.java
+ test/jdk/jshell/EditorTestBase.java
+ test/jdk/jshell/EmptyTest.java
+ test/jdk/jshell/ErrorTranslationTest.java
+ test/jdk/jshell/ExceptionsTest.java
+ test/jdk/jshell/ExpectedDiagnostic.java
+ test/jdk/jshell/ExternalEditorTest.java
+ test/jdk/jshell/HistoryTest.java
+ test/jdk/jshell/IOTest.java
+ test/jdk/jshell/IdGeneratorTest.java
+ test/jdk/jshell/IgnoreTest.java
+ test/jdk/jshell/IllegalArgumentExceptionTest.java
+ test/jdk/jshell/ImportTest.java
+ test/jdk/jshell/JShellStateClosedTest.java
+ test/jdk/jshell/KullaCompletenessStressTest.java
+ test/jdk/jshell/KullaTesting.java
+ test/jdk/jshell/MethodsTest.java
+ test/jdk/jshell/ModifiersTest.java
+ test/jdk/jshell/NullTest.java
+ test/jdk/jshell/RejectedFailedTest.java
+ test/jdk/jshell/ReplToolTesting.java
+ test/jdk/jshell/ReplaceTest.java
+ test/jdk/jshell/ShutdownTest.java
+ test/jdk/jshell/SimpleRegressionTest.java
+ test/jdk/jshell/SnippetStatusListenerTest.java
+ test/jdk/jshell/SnippetTest.java
+ test/jdk/jshell/StartOptionTest.java
+ test/jdk/jshell/StopExecutionTest.java
+ test/jdk/jshell/TestingInputStream.java
+ test/jdk/jshell/ToolBasicTest.java
+ test/jdk/jshell/TypeNameTest.java
+ test/jdk/jshell/VariablesTest.java

Changeset: 161940723360
Author:    sadayapalam
Date:      2015-10-20 15:25 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/161940723360

8139836: Can't use super::x method reference when x is protected
Summary: Javac incorrectly diasllows reference to a protected method from a super class in method reference expressions.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/MethodReference74.java
+ test/tools/javac/lambda/pkg/Parent.java

Changeset: 0cce85265987
Author:    sadayapalam
Date:      2015-10-21 17:52 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0cce85265987

8138729: javac -parameters should not emit parameter names for lambda expressions
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! test/tools/javac/MethodParameters/ClassFileVisitor.java
! test/tools/javac/MethodParameters/LambdaTest.java
! test/tools/javac/MethodParameters/LambdaTest.out
! test/tools/javac/MethodParameters/ReflectionVisitor.java

Changeset: 96a99cfb21be
Author:    lana
Date:      2015-10-21 18:40 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/96a99cfb21be

Merge


Changeset: 820841f0e8bd
Author:    alundblad
Date:      2015-10-22 09:05 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/820841f0e8bd

8087349: Test tools/sjavac/IncCompInheritance.java is failing
Summary: Refactoring of Dependencies framework.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/dependencies/NewDependencyCollector.java
! test/tools/javac/importscope/dependencies/DependenciesTest.java

Changeset: 4b374a9b4b22
Author:    sadayapalam
Date:      2015-10-22 16:18 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4b374a9b4b22

8074803: Name clash
Summary: Javac incorrectly reports a name clash.
Reviewed-by: mcimadamore

! 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/comp/TransTypes.java
+ test/tools/javac/NameClash/NameClashTest.java

Changeset: 86e463879ae7
Author:    mcimadamore
Date:      2015-10-22 18:58 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/86e463879ae7

8140333: Tweak langtools IntelliJ project to better support Kulla changes
Summary: Add support for target.java.home option to the idea target
Reviewed-by: jlahoda

! make/build.xml
! make/intellij/ant.xml
! make/intellij/workspace.xml

Changeset: b3f440e93b97
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b3f440e93b97

Merge


Changeset: b3ed4ac7cd91
Author:    sadayapalam
Date:      2015-10-23 08:21 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b3ed4ac7cd91

8057685: javac should not crash compiling type annotations
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
! test/tools/javac/annotations/typeAnnotations/newlocations/AllLocations.java

Changeset: 16873e56156e
Author:    aeriksso
Date:      2015-10-27 10:35 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/16873e56156e

8134759: jdb: Incorrect stepping inside finally block
Summary: Add LineNumberTable attribute for return bytecodes split around finally code
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/linenumbers/FinallyLineNumberTest.java

Changeset: 00a25f93cee8
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/00a25f93cee8

Added tag jdk9-b89 for changeset 16873e56156e

! .hgtags

Changeset: 49da3649b796
Author:    lana
Date:      2015-10-30 10:29 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/49da3649b796

Added tag jdk9-b90 for changeset 00a25f93cee8

! .hgtags

Changeset: 522e516b8a83
Author:    ksrini
Date:      2015-10-28 10:41 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/522e516b8a83

8132096: Augment the Compiler Tree API to support the new Simplified Doclet API
Reviewed-by: jjg, jlahoda

! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/tools/javac/doctree/DocCommentTester.java
! test/tools/javac/doctree/FirstSentenceTest.java
+ test/tools/javac/doctree/dcapi/DocCommentTreeApiTester.java
+ test/tools/javac/doctree/dcapi/OverviewTest.java
+ test/tools/javac/doctree/dcapi/overview0.html
+ test/tools/javac/doctree/dcapi/overview1.html
+ test/tools/javac/doctree/dcapi/overview2.html
+ test/tools/javac/doctree/dcapi/overview3.html
+ test/tools/javac/doctree/dcapi/overview4.html
+ test/tools/javac/doctree/dcapi/overview5.html
+ test/tools/javac/doctree/dcapi/overview6.html
+ test/tools/javac/doctree/dcapi/package.html
+ test/tools/javac/doctree/dcapi/pkg/Anchor.java
+ test/tools/javac/doctree/dcapi/pkg/package.html
! test/tools/javac/tree/NoPrivateTypesExported.java

Changeset: b278abcd113b
Author:    lana
Date:      2015-10-29 12:40 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b278abcd113b

Merge


Changeset: 79501a97ca57
Author:    lana
Date:      2015-11-04 13:46 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/79501a97ca57

Merge


Changeset: ab33a84365a0
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ab33a84365a0

Added tag jdk9-b91 for changeset 79501a97ca57

! .hgtags

Changeset: 03bb9c99b573
Author:    jlahoda
Date:      2015-10-30 17:00 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/03bb9c99b573

8140766: langtools/make/test/sym/CreateSymbolsTest.java contains incorrect paths
Summary: Fixing paths in CreateSymbolsTest; fixing imports in CreateSymbolsTestImpl.
Reviewed-by: mcimadamore

! make/test/sym/CreateSymbolsTest.java
! make/test/sym/CreateSymbolsTestImpl.java

Changeset: 19e44405ab4f
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/19e44405ab4f

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/gendata/Gendata-jdk.compiler.gmk

Changeset: 155f6671cab4
Author:    alundblad
Date:      2015-11-03 21:29 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/155f6671cab4

8137075: Sjavac tests are leaking file managers
Summary: Closing sjavac file managers.
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java
! test/tools/sjavac/ApiExtraction.java

Changeset: a32f899caa49
Author:    alundblad
Date:      2015-11-03 22:55 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a32f899caa49

8141355: PackagePathMismatch.java does not use --state-dir option
Summary: Added --state-dir to the PackagePathMismatch.java test.
Reviewed-by: jlahoda

! test/tools/sjavac/PackagePathMismatch.java

Changeset: 17d15aa9140d
Author:    alundblad
Date:      2015-11-04 12:27 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/17d15aa9140d

8139961: Various sjavac tests result in error on Windows (JPRT)
Summary: Test now closes Stream properly.
Reviewed-by: jlahoda

! test/tools/sjavac/NoState.java

Changeset: 3298cbc00d2f
Author:    mcimadamore
Date:      2015-11-05 11:32 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3298cbc00d2f

8141343: Subtle semantics changes for union types in cast conversion
Summary: cast applied to union types do not behave correctly and sometimes pass erroneously
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/8141343/T8141343.java
+ test/tools/javac/cast/8141343/T8141343.out

Changeset: a3415b57507c
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a3415b57507c

Merge


Changeset: 5245927b10eb
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/5245927b10eb

Added tag jdk9-b92 for changeset a3415b57507c

! .hgtags

Changeset: 16d09290bb2a
Author:    sadayapalam
Date:      2015-11-06 14:45 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/16d09290bb2a

8138612: Do not retain declaration annotations on lambda formal parameters
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForLambdaTest.java
+ test/tools/javac/lambda/SE5AnnotationsOnLambdaParameters.java

Changeset: ed4c306ec942
Author:    sadayapalam
Date:      2015-11-09 05:45 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ed4c306ec942

8129740: Incorrect class file created when passing lambda in inner class constructor
Summary: Lambda implementation method must be static when lambda is an argument to an explicit constructor call.
Reviewed-by: mcimadamore, jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
+ test/tools/javac/lambda/T8129740/AllowEnclosingVarCaptureTest.java
+ test/tools/javac/lambda/T8129740/CaptureInCtorChainingTest.java
+ test/tools/javac/lambda/T8129740/QualifiedThisAccessTest.java
+ test/tools/javac/lambda/T8129740/SourceForTranslation.java
+ test/tools/javac/lambda/T8129740/SourceToSourceTranslationTest.java
+ test/tools/javac/lambda/T8129740/Universe.java.out

Changeset: 424fba7cabb0
Author:    mcimadamore
Date:      2015-11-09 16:03 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/424fba7cabb0

8141639: Signatures in Lower could be made tighter by using JCExpression instead of JCTree
Summary: Make signatures of Lower methods more specific
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java

Changeset: 66a7e82d10a4
Author:    mcimadamore
Date:      2015-11-10 11:49 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/66a7e82d10a4

8141613: Compiler fails to infer generic type
Summary: Repeated capture of same expression leads to erroneous inference constraints
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/generics/inference/8141613/T8141613.java

Changeset: 2a83d2947323
Author:    sadayapalam
Date:      2015-11-11 17:13 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2a83d2947323

8142467: Remove all references Flags.IPROXY
Summary: Remove all references to flag bit IPROXY that has fallen into disuse.
Reviewed-by: mcimadamore

! 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/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java

Changeset: 60e39427dbd0
Author:    sadayapalam
Date:      2015-11-11 18:46 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/60e39427dbd0

8141508: java.lang.invoke.LambdaConversionException: Invalid receiver type
Summary: Incorrect handling of intersection type parameter of functional interface descriptor results in call site initialization exception
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/methodReference/IntersectionTypeReceiverTest.java

Changeset: 582f31e79d74
Author:    sadayapalam
Date:      2015-11-12 05:59 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/582f31e79d74

8142476: Call site initialization exception caused by LambdaConversionException: Invalid receiver type
Summary: Incorrect handling of intersection typed receiver in method references results in call site initialization exception
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/methodReference/IntersectionTypeReceiverTest2.java

Changeset: 3449ae78c6dc
Author:    sadayapalam
Date:      2015-11-12 06:13 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3449ae78c6dc

8136419: Type annotations in initializers and lambda bodies not written to class file
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/annotations/typeAnnotations/classfile/InstanceInitializer.java
+ test/tools/javac/annotations/typeAnnotations/classfile/StaticInitializer.java

Changeset: fdfaa0e5c8c0
Author:    sadayapalam
Date:      2015-11-12 08:39 +0530
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/fdfaa0e5c8c0

8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods
Summary: Improve clarity of javac messages by discriminating hiding scenerio from overriding
Reviewed-by: mcimadamore, sadayapalam
Contributed-by: srinivas.dama at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/OverrideChecks/T4720359a.out
+ test/tools/javac/OverrideChecks/T8139255.java
+ test/tools/javac/OverrideChecks/T8139255.out
+ test/tools/javac/diags/examples/HideStatic.java

Changeset: cf000bae9c31
Author:    shinyafox
Date:      2015-11-12 08:48 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/cf000bae9c31

8142384: JShell tool: New command: /imports, /i which show the list of imported packages or classes, etc...
Reviewed-by: rfield, jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! test/jdk/jshell/ReplToolTesting.java
! test/jdk/jshell/ToolBasicTest.java

Changeset: 329ae120e365
Author:    jlahoda
Date:      2015-11-12 15:10 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/329ae120e365

8141092: JShell: Completion hangs on identifier completion
Summary: Avoiding recursive search when computing package completion.
Reviewed-by: mcimadamore, rfield

! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! test/jdk/jshell/CompletionSuggestionTest.java

Changeset: 7f880f98506c
Author:    lana
Date:      2015-11-12 18:27 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/7f880f98506c

Merge


Changeset: 58525132b5b0
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/58525132b5b0

Added tag jdk9-b93 for changeset 7f880f98506c

! .hgtags

Changeset: 844a36d83020
Author:    mcimadamore
Date:      2015-11-24 00:42 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/844a36d83020

merge with b93

! make/build.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Operators.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
+ src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
+ test/tools/javac/lambda/T8129740/Universe.java.out


From maurizio.cimadamore at oracle.com  Tue Nov 24 01:21:40 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 01:21:40 +0000
Subject: hg: valhalla/valhalla/hotspot: Unsafe fixes
Message-ID: <201511240121.tAO1Le6X023211@aojmv0008.oracle.com>

Changeset: cd07c1abb185
Author:    mcimadamore
Date:      2015-11-24 01:20 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cd07c1abb185

Unsafe fixes

! src/share/vm/prims/unsafe.cpp


From maurizio.cimadamore at oracle.com  Tue Nov 24 09:45:35 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 09:45:35 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: jshell should understand extra
	valhalla tokens
Message-ID: <201511240945.tAO9jZ4B011808@aojmv0008.oracle.com>

Changeset: 08f35559a66d
Author:    mcimadamore
Date:      2015-11-24 09:45 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/08f35559a66d

Fix: jshell should understand extra valhalla tokens
Contributed-by: jan.lahoda at oracle.com

! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java


From maurizio.cimadamore at oracle.com  Tue Nov 24 10:02:19 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 10:02:19 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Compiler should forbid attempts
	to synchronize on value instances.
Message-ID: <201511241002.tAOA2JPN016803@aojmv0008.oracle.com>

Changeset: 01e9ba0e9e8d
Author:    mcimadamore
Date:      2015-11-24 10:01 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/01e9ba0e9e8d

Fix: Compiler should forbid attempts to synchronize on value instances.
Contributed-by: srikanth.adayapalam at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/valhalla/values/CheckSynchronized.java
+ test/tools/javac/valhalla/values/CheckSynchronized.out


From maurizio.cimadamore at oracle.com  Tue Nov 24 13:14:16 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 13:14:16 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: add support for
	abstract peels in methods
Message-ID: <201511241314.tAODEH1K018764@aojmv0008.oracle.com>

Changeset: 85d6aa1e1c79
Author:    mcimadamore
Date:      2015-11-24 13:13 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/85d6aa1e1c79

Enhancement: add support for abstract peels in methods

Example:

    interface Foo<any X> {
        void m() {
            __WhereRef(X) { System.out.println("Hello!"); }
            __WhereVal(X) abstract
        }
    }

    class SubRef implements Foo<String> { } //ok
    class SubVal implements Foo<int> { } //error

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/valhalla/typespec/AbstractPeel01.java
+ test/tools/javac/valhalla/typespec/AbstractPeel02.java
+ test/tools/javac/valhalla/typespec/AbstractPeel02.out
+ test/tools/javac/valhalla/typespec/AbstractPeel03.java
+ test/tools/javac/valhalla/typespec/AbstractPeel03.out
+ test/tools/javac/valhalla/typespec/TestRefOnly10.java
+ test/tools/javac/valhalla/typespec/TestRefOnly10.out
! test/tools/javac/valhalla/typespec/items/tests/TestValOnly.java


From maurizio.cimadamore at oracle.com  Tue Nov 24 13:15:03 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 13:15:03 +0000
Subject: hg: valhalla/valhalla: Fixes to IntelliJ project
Message-ID: <201511241315.tAODF3xv019392@aojmv0008.oracle.com>

Changeset: 800ffe42f62e
Author:    mcimadamore
Date:      2015-11-24 13:14 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/800ffe42f62e

Fixes to IntelliJ project

! make/idea/idea.gmk
! make/idea/template/build.xml
+ make/idea/template/jdk.iml
! make/idea/template/src/idea/JdkIdeaAntLogger.java
! make/idea/template/workspace.xml


From maurizio.cimadamore at oracle.com  Tue Nov 24 13:46:54 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 13:46:54 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: Missing normalization on
	anyfied array index access.
Message-ID: <201511241346.tAODksc6000899@aojmv0008.oracle.com>

Changeset: 411dc20edc4e
Author:    mcimadamore
Date:      2015-11-24 13:46 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/411dc20edc4e

Fix: Missing normalization on anyfied array index access.

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/valhalla/typespec/Wildcards11.java


From maurizio.cimadamore at oracle.com  Tue Nov 24 18:14:07 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 18:14:07 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: add specializer loader support
	to jshell
Message-ID: <201511241814.tAOIE7fH024311@aojmv0008.oracle.com>

Changeset: 2c063d193da6
Author:    mcimadamore
Date:      2015-11-24 18:13 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/2c063d193da6

Fix: add specializer loader support to jshell
Contributed-by: jan.lahoda at oracle.com

! make/build.properties
+ src/jdk.jshell/share/classes/META-INF/services/java.net.spi.URLStreamHandlerProvider
! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteClassLoader.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/StreamHandlerFactoryImpl.java
+ test/jdk/jshell/SpecializationTest.java


From maurizio.cimadamore at oracle.com  Tue Nov 24 18:30:10 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 18:30:10 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: cleanup langtools build
Message-ID: <201511241830.tAOIUGxv002017@aojmv0008.oracle.com>

Changeset: 018ef6762d6e
Author:    mcimadamore
Date:      2015-11-24 18:29 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/018ef6762d6e

Enhancement: cleanup langtools build
Contributed-by: jan.lahoda at oracle.com

! make/build.properties
! make/build.xml


From maurizio.cimadamore at oracle.com  Wed Nov 25 10:55:59 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Nov 2015 10:55:59 +0000
Subject: hg: valhalla/valhalla: Fix: add export to modules.xml to allow make
	images to terminate
Message-ID: <201511251055.tAPAtxkB019590@aojmv0008.oracle.com>

Changeset: 244a4fdfb7ef
Author:    mcimadamore
Date:      2015-11-25 10:55 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/244a4fdfb7ef

Fix: add export to modules.xml to allow make images to terminate

! modules.xml


From boaznahum at gmail.com  Sat Nov 28 18:51:26 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Sat, 28 Nov 2015 18:51:26 +0000
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
Message-ID: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>

Hi.
(Please correct me if I need to send to different group)
I'm building valhalla on daily basis, lately I have a little problem with
g1ParScanThreadState.cpp

I tried to configure with '--disable-warnings-as-errors' - no luck

Compiling 72 files for java.sql
Compiling 281 files for java.xml.crypto
F:\Dev\JDK8Build\valhalla\hotspot\src\share\vm\gc\g1\g1ParScanThreadState.cpp(46)
: warning C4355: 'this' : used in base member initializer list
Compiling 50 files for java.sql.rowset
NMAKE : fatal error U1077: 'D:\ProgFiles\VS10.0\VC\BIN\amd64\cl.exe' :
return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'D:\ProgFiles\VS10.0\VC\BIN\amd64\nmake.EXE' :
return code '0x2'
Stop.
Makefile:230: recipe for target 'generic_build2' failedmake[5]: ***
[generic_build2] Error 2

Please note that I tried temporarily replacing 'this' with 'NULL' - I just
got the same error in other file. So I gave up:

Thank
Boaz

From sebastian.sickelmann at gmx.de  Sun Nov 29 16:25:07 2015
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sun, 29 Nov 2015 17:25:07 +0100
Subject: Broken link on project-website
Message-ID: <565B26E3.7080909@gmx.de>

Hi,

i think to link for Generic Specialization is broken. I think instead of
http://openjdk.java.net/jeps/8046267 it should be
https://bugs.openjdk.java.net/browse/JDK-8046267.

Is there a way to fix such small typing error directly. Or is the
mailing-list always the best-way?

--
Sebastian



From martijnverburg at gmail.com  Sun Nov 29 19:19:24 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 29 Nov 2015 19:19:24 +0000
Subject: Broken link on project-website
In-Reply-To: <565B26E3.7080909@gmx.de>
References: <565B26E3.7080909@gmx.de>
Message-ID: <CAP7YuAQE_wiONk9CH6kwKXts=kaUh6i4StUu9T-T+UjvS+RaZA@mail.gmail.com>

Mailing list for now is the correct way. I maintain the page on Valhalla's
behalf but I also need to manually exchange files with someone who has
access to OpenJDK.java.net project pages (it's one of the small areas we
hope to see stored in mercurial next year).

I'll fix the link and send in an updated page

Cheers,
Martijn

On Sunday, 29 November 2015, Sebastian Sickelmann <
sebastian.sickelmann at gmx.de> wrote:

> Hi,
>
> i think to link for Generic Specialization is broken. I think instead of
> http://openjdk.java.net/jeps/8046267 it should be
> https://bugs.openjdk.java.net/browse/JDK-8046267.
>
> Is there a way to fix such small typing error directly. Or is the
> mailing-list always the best-way?
>
> --
> Sebastian
>
>
>

-- 
Cheers, Martijn (Sent from Gmail Mobile)

From maurizio.cimadamore at oracle.com  Sun Nov 29 21:52:56 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 29 Nov 2015 21:52:56 +0000
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
In-Reply-To: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
References: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
Message-ID: <565B73B8.6010102@oracle.com>

Hi Boaz,
this:

http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014773.html

and this:

http://mail.openjdk.java.net/pipermail/build-dev/2015-August/015418.html

Seem related - you might find some solutions there to either workaround 
the issue, or to disable warnings as errors for real.

Maurizio


On 28/11/15 18:51, Boaz Nahum wrote:
> Hi.
> (Please correct me if I need to send to different group)
> I'm building valhalla on daily basis, lately I have a little problem with
> g1ParScanThreadState.cpp
>
> I tried to configure with '--disable-warnings-as-errors' - no luck
>
> Compiling 72 files for java.sql
> Compiling 281 files for java.xml.crypto
> F:\Dev\JDK8Build\valhalla\hotspot\src\share\vm\gc\g1\g1ParScanThreadState.cpp(46)
> : warning C4355: 'this' : used in base member initializer list
> Compiling 50 files for java.sql.rowset
> NMAKE : fatal error U1077: 'D:\ProgFiles\VS10.0\VC\BIN\amd64\cl.exe' :
> return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'D:\ProgFiles\VS10.0\VC\BIN\amd64\nmake.EXE' :
> return code '0x2'
> Stop.
> Makefile:230: recipe for target 'generic_build2' failedmake[5]: ***
> [generic_build2] Error 2
>
> Please note that I tried temporarily replacing 'this' with 'NULL' - I just
> got the same error in other file. So I gave up:
>
> Thank
> Boaz


From volker.simonis at gmail.com  Mon Nov 30 07:59:10 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 30 Nov 2015 08:59:10 +0100
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
In-Reply-To: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
References: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
Message-ID: <CA+3eh13i+mmNDZXFa60gSZ9TMKji1idjXsm-Abd6zbq_1_DKfw@mail.gmail.com>

Hi Boaz,

I'm a little confused about which hotspot version the valhalla repo is
based on. Your output mentions "JDK8Build" but from the path and line
information this should be jdk9.

That said, I think your problem is related to "8141134: Remove unnecessary
pragma warning(disable:4355) from GC code (
https://bugs.openjdk.java.net/browse/JDK-8141134)". It removed the pragma
which suppressed the warning C4355 from several files, but instead added it
globally for  VS less than 2013 (i.e. _MSC_VER < 1800) which should match
your compiler. You should have the following code in
src/share/vm/utilities/globalDefinitions_visCPP.hpp:

#if _MSC_VER < 1800
// Visual Studio 2013 introduced strtoull(); before, one has to use
_strtoui64() instead.
#define strtoull _strtoui64
// Fixes some wrong warnings about 'this' : used in base member initializer
list
#pragma warning( disable : 4355 )
#endif

If it's not there, you should just sync valhalla with the latest jdk9 or
use VS2013 or newer.

Regards,
Volker


On Sat, Nov 28, 2015 at 7:51 PM, Boaz Nahum <boaznahum at gmail.com> wrote:

> Hi.
> (Please correct me if I need to send to different group)
> I'm building valhalla on daily basis, lately I have a little problem with
> g1ParScanThreadState.cpp
>
> I tried to configure with '--disable-warnings-as-errors' - no luck
>
> Compiling 72 files for java.sql
> Compiling 281 files for java.xml.crypto
>
> F:\Dev\JDK8Build\valhalla\hotspot\src\share\vm\gc\g1\g1ParScanThreadState.cpp(46)
> : warning C4355: 'this' : used in base member initializer list
> Compiling 50 files for java.sql.rowset
> NMAKE : fatal error U1077: 'D:\ProgFiles\VS10.0\VC\BIN\amd64\cl.exe' :
> return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'D:\ProgFiles\VS10.0\VC\BIN\amd64\nmake.EXE' :
> return code '0x2'
> Stop.
> Makefile:230: recipe for target 'generic_build2' failedmake[5]: ***
> [generic_build2] Error 2
>
> Please note that I tried temporarily replacing 'this' with 'NULL' - I just
> got the same error in other file. So I gave up:
>
> Thank
> Boaz
>

From maurizio.cimadamore at oracle.com  Mon Nov 30 10:43:45 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 30 Nov 2015 10:43:45 +0000
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
In-Reply-To: <CA+3eh13i+mmNDZXFa60gSZ9TMKji1idjXsm-Abd6zbq_1_DKfw@mail.gmail.com>
References: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
	<CA+3eh13i+mmNDZXFa60gSZ9TMKji1idjXsm-Abd6zbq_1_DKfw@mail.gmail.com>
Message-ID: <565C2861.7050004@oracle.com>



On 30/11/15 07:59, Volker Simonis wrote:
> If it's not there, you should just sync valhalla with the latest jdk9 or
> use VS2013 or newer.
Valhalla has been synced last week to jdk9 b93, so it should be fairly 
recent. But it seems like this particular fix is very recent and hasn't 
made it to b93.

Maurizio

From maurizio.cimadamore at oracle.com  Mon Nov 30 11:00:06 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 30 Nov 2015 11:00:06 +0000
Subject: hg: valhalla/valhalla/hotspot: 8141134: Remove unnecessary pragma
	warning(disable:4355) from GC code
Message-ID: <201511301100.tAUB06oq028982@aojmv0008.oracle.com>

Changeset: a941edf7dae2
Author:    mcimadamore
Date:      2015-11-30 10:59 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a941edf7dae2

8141134: Remove unnecessary pragma warning(disable:4355) from GC code
Reviewed-by: ehelin, simonis, stuefe

! src/share/vm/code/nmethod.cpp
! src/share/vm/gc/cms/parNewGeneration.cpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/dirtyCardQueue.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/satbQueue.cpp
! src/share/vm/utilities/globalDefinitions_visCPP.hpp


From maurizio.cimadamore at oracle.com  Mon Nov 30 11:00:44 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 30 Nov 2015 11:00:44 +0000
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
In-Reply-To: <565C2861.7050004@oracle.com>
References: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
	<CA+3eh13i+mmNDZXFa60gSZ9TMKji1idjXsm-Abd6zbq_1_DKfw@mail.gmail.com>
	<565C2861.7050004@oracle.com>
Message-ID: <565C2C5C.2060805@oracle.com>

I've pushed the fix indicated by Volker (thanks!). Let me know if you 
see some improvements.

Maurizio

On 30/11/15 10:43, Maurizio Cimadamore wrote:
>
>
> On 30/11/15 07:59, Volker Simonis wrote:
>> If it's not there, you should just sync valhalla with the latest jdk9 or
>> use VS2013 or newer.
> Valhalla has been synced last week to jdk9 b93, so it should be fairly 
> recent. But it seems like this particular fix is very recent and 
> hasn't made it to b93.
>
> Maurizio


From martijnverburg at gmail.com  Mon Nov 30 11:34:31 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 30 Nov 2015 11:34:31 +0000
Subject: Monthly notice for new signups to Project Valhalla - How to Contribute
Message-ID: <CAP7YuAQR+_6gQdFTc7zCaQyLbwmqBp9Z-ETOOamQ992oMTcusA@mail.gmail.com>

Hi all,

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 boaznahum at gmail.com  Mon Nov 30 19:58:02 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Mon, 30 Nov 2015 19:58:02 +0000
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
In-Reply-To: <565C2C5C.2060805@oracle.com>
References: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
	<CA+3eh13i+mmNDZXFa60gSZ9TMKji1idjXsm-Abd6zbq_1_DKfw@mail.gmail.com>
	<565C2861.7050004@oracle.com> <565C2C5C.2060805@oracle.com>
Message-ID: <CAB_DFWavOq8yxSfCbQjxiNVFBRcLS9dcye=r8SRd0Dd94_AMNA@mail.gmail.com>

Thank you every one. Now it works.

If you are interested, here is the crash report after attempting a simple
compilation(Worked in the past)
===Begin here ===================================================
Information:11/30/2015 7:52 PM - Compilation completed with 1 error and 0
warnings in 9ms
Error:Abnormal build process termination:
Build process started. Classpath:
/F:/Dev/Tools/IntelliJ/15c/15.0.1x/lib/jps-launcher.jar;F:/Dev/JDK8Build/valhalla/build/windows-x86_64-normal-server-release/images/jdk/lib/tools.jar;/F:/Dev/Tools/IntelliJ/15c/15.0.1x/lib/optimizedFileManager.jar;F:/Dev/Tools/IntelliJ/15c/15.0.1x/lib/ecj-4.4.jar
[thread 9596 also had an error][thread 11872 also had an error][thread 3644
also had an error]
[thread 2676 also had an error]
[thread 10700 also had an error]
[thread 7676 also had an error]
[thread 11040 also had an error]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006d187dc2,
pid=10548, tid=6568
#
# JRE version: OpenJDK Runtime Environment (9.0) (build
1.9.0-internal-boaz_2015_11_30_19_19-b00)
# Java VM: OpenJDK 64-Bit Server VM
(1.9.0-internal-boaz_2015_11_30_19_19-b00, mixed mode, tiered, compressed
oops, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x3e7dc2]#
# No core dump will be written. Minidumps are not enabled by default on
client versions of Windows
#
# An error report file with more information is saved as:
# F:\Dev\Tools\IntelliJ\15c\system\compile-server\hs_err_pid10548.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

===End here ===================================================

Boaz



On Mon, Nov 30, 2015 at 1:00 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I've pushed the fix indicated by Volker (thanks!). Let me know if you
> see some improvements.
>
> Maurizio
>
> On 30/11/15 10:43, Maurizio Cimadamore wrote:
> >
> >
> > On 30/11/15 07:59, Volker Simonis wrote:
> >> If it's not there, you should just sync valhalla with the latest jdk9 or
> >> use VS2013 or newer.
> > Valhalla has been synced last week to jdk9 b93, so it should be fairly
> > recent. But it seems like this particular fix is very recent and
> > hasn't made it to b93.
> >
> > Maurizio
>
>

From boaznahum at gmail.com  Mon Nov 30 20:22:00 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Mon, 30 Nov 2015 20:22:00 +0000
Subject: Fail to build on windows 'g1ParScanThreadState.cpp'
In-Reply-To: <CAB_DFWavOq8yxSfCbQjxiNVFBRcLS9dcye=r8SRd0Dd94_AMNA@mail.gmail.com>
References: <CAB_DFWaf4ErWJuLNHBiVL4jJO6PD9FHKtDkPXoBJPR8rY091oA@mail.gmail.com>
	<CA+3eh13i+mmNDZXFa60gSZ9TMKji1idjXsm-Abd6zbq_1_DKfw@mail.gmail.com>
	<565C2861.7050004@oracle.com> <565C2C5C.2060805@oracle.com>
	<CAB_DFWavOq8yxSfCbQjxiNVFBRcLS9dcye=r8SRd0Dd94_AMNA@mail.gmail.com>
Message-ID: <CAB_DFWbjd7BgMdjOccejVece47A6dD9ck7t_c7h_z7fi2cCTXw@mail.gmail.com>

SORRY !!!

forget to undo g1ParScanThreadState.cpp(46) with _scanner(g1h, *NULL*),

On Mon, Nov 30, 2015 at 7:58 PM Boaz Nahum <boaznahum at gmail.com> wrote:

> Thank you every one. Now it works.
>
> If you are interested, here is the crash report after attempting a simple
> compilation(Worked in the past)
> ===Begin here ===================================================
> Information:11/30/2015 7:52 PM - Compilation completed with 1 error and 0
> warnings in 9ms
> Error:Abnormal build process termination:
> Build process started. Classpath:
> /F:/Dev/Tools/IntelliJ/15c/15.0.1x/lib/jps-launcher.jar;F:/Dev/JDK8Build/valhalla/build/windows-x86_64-normal-server-release/images/jdk/lib/tools.jar;/F:/Dev/Tools/IntelliJ/15c/15.0.1x/lib/optimizedFileManager.jar;F:/Dev/Tools/IntelliJ/15c/15.0.1x/lib/ecj-4.4.jar
> [thread 9596 also had an error][thread 11872 also had an error][thread
> 3644 also had an error]
> [thread 2676 also had an error]
> [thread 10700 also had an error]
> [thread 7676 also had an error]
> [thread 11040 also had an error]
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006d187dc2,
> pid=10548, tid=6568
> #
> # JRE version: OpenJDK Runtime Environment (9.0) (build
> 1.9.0-internal-boaz_2015_11_30_19_19-b00)
> # Java VM: OpenJDK 64-Bit Server VM
> (1.9.0-internal-boaz_2015_11_30_19_19-b00, mixed mode, tiered, compressed
> oops, g1 gc, windows-amd64)
> # Problematic frame:
> # V  [jvm.dll+0x3e7dc2]#
> # No core dump will be written. Minidumps are not enabled by default on
> client versions of Windows
> #
> # An error report file with more information is saved as:
> # F:\Dev\Tools\IntelliJ\15c\system\compile-server\hs_err_pid10548.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> #
>
> ===End here ===================================================
>
> Boaz
>
>
>
> On Mon, Nov 30, 2015 at 1:00 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> I've pushed the fix indicated by Volker (thanks!). Let me know if you
>> see some improvements.
>>
>> Maurizio
>>
>> On 30/11/15 10:43, Maurizio Cimadamore wrote:
>> >
>> >
>> > On 30/11/15 07:59, Volker Simonis wrote:
>> >> If it's not there, you should just sync valhalla with the latest jdk9
>> or
>> >> use VS2013 or newer.
>> > Valhalla has been synced last week to jdk9 b93, so it should be fairly
>> > recent. But it seems like this particular fix is very recent and
>> > hasn't made it to b93.
>> >
>> > Maurizio
>>
>>

From maurizio.cimadamore at oracle.com  Tue Nov 24 01:04:28 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Nov 2015 01:04:28 -0000
Subject: hg: valhalla/valhalla/hotspot: 288 new changesets
Message-ID: <201511240104.tAO14Nln020408@aojmv0008.oracle.com>

Changeset: b0e0a53226fd
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b0e0a53226fd

Added tag jdk9-b88 for changeset bc48b669bc66

! .hgtags

Changeset: e1517978bf12
Author:    enevill
Date:      2015-09-15 12:59 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e1517978bf12

8136524: aarch64: test/compiler/runtime/7196199/Test7196199.java fails
Summary: Fix safepoint handlers to save 128 bits on vector poll
Reviewed-by: kvn
Contributed-by: felix.yang at linaro.org

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: 43451068d53c
Author:    roland
Date:      2015-09-15 13:08 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/43451068d53c

8136461: PhaseIdealLoop::try_move_store_before_loop() may bypass early loop exit
Summary: PhaseIdealLoop::try_move_store_before_loop() needs to check for early loop exit before candidate Stores
Reviewed-by: kvn

! src/share/vm/opto/loopopts.cpp
- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
+ test/compiler/loopopts/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: cc267038a9c1
Author:    kvn
Date:      2015-09-15 11:04 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cc267038a9c1

8136406: Remove ZapDeadCompiledLocals code
Summary: Dead code elimination.
Reviewed-by: roland, twisti

! agent/src/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapSet.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 65c21ccab1bd
Author:    kvn
Date:      2015-09-16 20:33 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/65c21ccab1bd

Merge


Changeset: 10e79692c25e
Author:    mcberg
Date:      2015-09-16 13:16 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/10e79692c25e

8134802: LCM register pressure scheduling
Summary: Calculate register pressure in a block to help instructions scheduling.
Reviewed-by: kvn, dlong

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/c2_globals_aarch64.hpp
! src/cpu/ppc/vm/c2_globals_ppc.hpp
! src/cpu/ppc/vm/ppc.ad
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/node.hpp

Changeset: a60e232aa8f2
Author:    kvn
Date:      2015-09-16 15:54 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a60e232aa8f2

8134553: CRC32C implementations for x86/x64 targets
Reviewed-by: kvn
Contributed-by: tomasz.wojtowicz at intel.com

! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
+ src/cpu/x86/vm/crc32c.h
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86.cpp
! src/cpu/x86/vm/stubRoutines_x86.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/zero/vm/interpreterGenerator_zero.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6d9d273e7f0d
Author:    thartmann
Date:      2015-09-17 08:08 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6d9d273e7f0d

8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts
Summary: Bail out of superword optimization if loop was removed (i.e., if zero-trip Opaque1Node was removed).
Reviewed-by: kvn, roland

! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/superword.cpp

Changeset: 476739c20b35
Author:    iveresov
Date:      2015-09-17 13:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/476739c20b35

Merge


Changeset: e3201914b83b
Author:    neliasso
Date:      2015-09-18 10:11 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e3201914b83b

8135068: Extract method matchers from CompilerOracle
Summary: Ecapsulate code to enable reuse
Reviewed-by: roland, kvn

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
+ src/share/vm/compiler/methodMatcher.cpp
+ src/share/vm/compiler/methodMatcher.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/globals.hpp
! test/compiler/c2/5091921/Test7005594.sh
! test/compiler/oracle/CheckCompileCommandOption.java
+ test/compiler/oracle/MethodMatcherTest.java
! test/compiler/oracle/TestCompileCommand.java
! test/compiler/oracle/command1.txt
! test/runtime/CommandLine/CompilerConfigFileWarning.java

Changeset: 17efe8fc4f48
Author:    mdoerr
Date:      2015-09-17 09:03 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/17efe8fc4f48

8136525: Generate interpreter entries only once and avoid unnecessary jump to jump
Reviewed-by: coleenp, twisti, aph

! src/cpu/aarch64/vm/interp_masm_aarch64.cpp
! src/cpu/aarch64/vm/interp_masm_aarch64.hpp
! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
! src/cpu/aarch64/vm/interpreter_aarch64.cpp
! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp
! src/cpu/ppc/vm/interp_masm_ppc_64.cpp
! src/cpu/ppc/vm/interp_masm_ppc_64.hpp
! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp
! src/cpu/ppc/vm/interpreter_ppc.cpp
! src/cpu/ppc/vm/templateInterpreter_ppc.cpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interp_masm_x86.cpp
! src/cpu/x86/vm/interp_masm_x86.hpp
! src/cpu/x86/vm/interpreterGenerator_x86.cpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp

Changeset: 3ac528612681
Author:    coleenp
Date:      2015-09-18 16:37 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3ac528612681

Merge


Changeset: 3b908f10337f
Author:    tpivovarova
Date:      2015-09-19 12:03 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3b908f10337f

8136693: add package statement 'compiler.testlibrary' to CompilerUtils
Reviewed-by: iignatyev

! test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java
! test/compiler/testlibrary/CompilerUtils.java

Changeset: d61e3154b6e0
Author:    dpochepk
Date:      2015-09-19 12:04 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d61e3154b6e0

8136718: [TESTBUG] introduce FileInstaller functionality
Reviewed-by: iignatyev

+ test/testlibrary/jdk/test/lib/FileInstaller.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: bab9d3d37ae8
Author:    iignatyev
Date:      2015-09-19 11:19 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bab9d3d37ae8

Merge


Changeset: 95e96bd4b70b
Author:    adinn
Date:      2015-09-16 09:52 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/95e96bd4b70b

8080293: AARCH64: Remove unnecessary dmbs from generated CAS code
Summary: The current encoding for CAS generates unnecessary leading and trailing dmbs for the MemBarAcquire and MemBarRelease which ought to be elided
Reviewed-by: kvn

! src/cpu/aarch64/vm/aarch64.ad

Changeset: 66d90f141fd8
Author:    zmajo
Date:      2015-09-22 13:42 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/66d90f141fd8

8136914: compiler/loopopts/superword/SumRedSqrt_Double.java times out
Summary: Change test to execute only on relevant (x86-based) platforms.
Reviewed-by: kvn, dlong

! test/compiler/loopopts/superword/SumRedSqrt_Double.java

Changeset: 6cc606e29b74
Author:    roland
Date:      2015-09-21 10:51 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6cc606e29b74

8136596: Remove aarch64: MemBarRelease when final field's allocation is NoEscape or ArgEscape
Summary: elide MemBar when AllocateNode _is_non_escaping
Reviewed-by: kvn, roland
Contributed-by: hui.shi at linaro.org

! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp

Changeset: 7c288547a709
Author:    roland
Date:      2015-09-22 15:25 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7c288547a709

8136926: phi == NULL assert in PhaseIdealLoop::try_move_store_after_loop
Summary: multiple phis on same slice are possible in a loop
Reviewed-by: kvn, mcberg

! src/share/vm/opto/loopopts.cpp
! test/compiler/loopopts/TestMoveStoresOutOfLoops.java

Changeset: db3a3feccd9b
Author:    enevill
Date:      2015-09-16 13:50 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/db3a3feccd9b

8136615: aarch64: elide DecodeN when followed by CmpP 0
Summary: remove DecodeN when comparing a narrow oop with 0
Reviewed-by: kvn, adinn

! src/cpu/aarch64/vm/aarch64.ad

Changeset: 56024013648f
Author:    kzhaldyb
Date:      2015-09-24 18:24 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/56024013648f

8137020: [TESTBUG] Utils.runAndCheckException doesn't work well if no exception thrown
Summary: Changed handling a case when expected exception wasn't thrown
Reviewed-by: iignatyev

! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 0855eb2338ae
Author:    ppunegov
Date:      2015-09-24 20:13 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0855eb2338ae

8066157: JEP-JDK-8046155: Test task: method matcher
Summary: MethodMatcher test and framework
Reviewed-by: iignatyev, neliasso

+ test/compiler/compilercontrol/matcher/MethodMatcherTest.java
+ test/compiler/compilercontrol/share/method/ClassType.java
+ test/compiler/compilercontrol/share/method/MethodDescriptor.java
+ test/compiler/compilercontrol/share/method/MethodElementType.java
+ test/compiler/compilercontrol/share/method/MethodGenerator.java
+ test/compiler/compilercontrol/share/method/MethodType.java
+ test/compiler/compilercontrol/share/method/SignatureType.java
+ test/compiler/compilercontrol/share/pool/MethodHolder.java
+ test/compiler/compilercontrol/share/pool/PoolHelper.java
+ test/compiler/compilercontrol/share/pool/sub/Klass.java
+ test/compiler/compilercontrol/share/pool/sub/KlassDup.java
+ test/compiler/compilercontrol/share/pool/subpack/Klass.java
+ test/compiler/compilercontrol/share/pool/subpack/KlassDup.java
+ test/testlibrary/jdk/test/lib/Pair.java
+ test/testlibrary/jdk/test/lib/Triple.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: df910cc4b9ea
Author:    roland
Date:      2015-09-17 16:53 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/df910cc4b9ea

8136820: Generate better code for some Unsafe addressing patterns
Summary: reshape address computation to move invariant part out of loops
Reviewed-by: kvn

! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/superword.cpp

Changeset: 8096c5205545
Author:    iveresov
Date:      2015-09-25 12:04 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8096c5205545

Merge

! src/cpu/aarch64/vm/interp_masm_aarch64.cpp
! src/cpu/ppc/vm/interp_masm_ppc_64.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/x86/vm/interp_masm_x86.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp
- test/gc/logging/TestPrintReferences.java
- test/gc/startup_warnings/TestDefaultMaxRAMFraction.java
- test/gc/startup_warnings/TestNoParNew.java

Changeset: 5ee8eccf7900
Author:    aph
Date:      2015-09-28 16:18 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5ee8eccf7900

8136165: AARCH64: Tidy up compiled native calls
Summary: Do some cleaning
Reviewed-by: roland, kvn, enevill

! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: fa430fa4f577
Author:    enevill
Date:      2015-09-23 12:39 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fa430fa4f577

8135231: aarch64: add support for vectorizing double precision sqrt
Reviewed-by: roland, aph

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/assembler_aarch64.hpp
! test/compiler/loopopts/superword/SumRedSqrt_Double.java

Changeset: f244d455e4dd
Author:    amurillo
Date:      2015-10-01 11:52 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f244d455e4dd

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: 5ab466809f05
Author:    iveresov
Date:      2015-10-08 09:51 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5ab466809f05

8139094: Tier1 test java/util/zip/TestCRC32C.java fails due to fixes for JDK-8134553
Summary: Match correct intrinsic kind
Reviewed-by: iveresov, kvn
Contributed-by: tomasz.wojtowicz at intel.com

! src/cpu/x86/vm/templateInterpreter_x86_32.cpp

Changeset: daf8acf3afda
Author:    enevill
Date:      2015-09-30 04:35 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/daf8acf3afda

8138583: aarch64: add support for vectorizing fabs/fneg
Reviewed-by: aph, roland
Contributed-by: felix.yang at linaro.org

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/assembler_aarch64.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
+ test/compiler/loopopts/superword/SumRedAbsNeg_Double.java
+ test/compiler/loopopts/superword/SumRedAbsNeg_Float.java

Changeset: 324ea1a2419a
Author:    iveresov
Date:      2015-10-05 20:02 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/324ea1a2419a

8132207: update for x86 exp in the math lib
Summary: Add new java.lang.Math() intrinsics from x86
Reviewed-by: kvn, iveresov
Contributed-by: vivek.r.deshpande at intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
+ src/cpu/x86/vm/macroAssembler_x86_libm.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 30f10e51ad6f
Author:    adinn
Date:      2015-10-07 06:56 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/30f10e51ad6f

8139042: AARCH64: Correct regression introduced by 8080293
Summary: Reinstate unsafe volatile optimization broken by JDK-8080293
Reviewed-by: aph, kvn

! src/cpu/aarch64/vm/aarch64.ad

Changeset: 017224c13b0e
Author:    dlong
Date:      2015-10-08 19:16 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/017224c13b0e

Merge


Changeset: f01629221703
Author:    amurillo
Date:      2015-10-08 14:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f01629221703

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: eca671f4c014
Author:    ecaspole
Date:      2015-09-21 10:36 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/eca671f4c014

8131645: [ARM64] crash on Cavium when using G1
Summary: Add a fence when creating the CodeRootSetTable so the readers do not see invalid memory.
Reviewed-by: aph, tschatzl

! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp

Changeset: c55ee4af240d
Author:    ctornqvi
Date:      2015-09-23 05:18 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c55ee4af240d

8027565: Enable /d2Zi+ when building with Visual Studio 2013
Reviewed-by: dcubed, ihse

! make/windows/makefiles/compile.make

Changeset: 1ce8347eea86
Author:    ddmitriev
Date:      2015-09-23 22:04 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1ce8347eea86

8073331: [TESTBUG] Test for VM option file feature (VM options specified in file)
Reviewed-by: dcubed, gtriantafill, rdurbin

+ test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java
+ test/runtime/CommandLine/VMOptionsFile/flags_file
+ test/runtime/CommandLine/VMOptionsFile/optionFILE_2
+ test/runtime/CommandLine/VMOptionsFile/optionfile_1
+ test/runtime/CommandLine/VMOptionsFile/optionfile_3
+ test/runtime/CommandLine/VMOptionsFile/optionfile_bad_option
+ test/runtime/CommandLine/VMOptionsFile/optionfile_long_property
+ test/runtime/CommandLine/VMOptionsFile/optionfile_lot_of_options_quote
+ test/runtime/CommandLine/VMOptionsFile/optionfile_only_tabsandspaces
+ test/runtime/CommandLine/VMOptionsFile/optionfile_quote
+ test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size
+ test/runtime/CommandLine/VMOptionsFile/optionfile_unmatched_quote_1
+ test/runtime/CommandLine/VMOptionsFile/optionfile_unmatched_quote_2
+ test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property

Changeset: 91c907c47794
Author:    aph
Date:      2015-09-24 12:04 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/91c907c47794

8135018: AARCH64: Missing memory barriers for CMS collector
Summary: Add StoreStore barrier when CMS needs them
Reviewed-by: tschatzl

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp

Changeset: f99ad7bb5df5
Author:    mlarsson
Date:      2015-09-24 12:36 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f99ad7bb5df5

8046148: JEP 158: Unified JVM Logging
Reviewed-by: coleenp, sla

! make/windows/makefiles/vm.make
! src/share/vm/Xusage.txt
+ src/share/vm/logging/log.hpp
+ src/share/vm/logging/logConfiguration.cpp
+ src/share/vm/logging/logConfiguration.hpp
+ src/share/vm/logging/logDecorations.cpp
+ src/share/vm/logging/logDecorations.hpp
+ src/share/vm/logging/logDecorators.cpp
+ src/share/vm/logging/logDecorators.hpp
+ src/share/vm/logging/logDiagnosticCommand.cpp
+ src/share/vm/logging/logDiagnosticCommand.hpp
+ src/share/vm/logging/logFileOutput.cpp
+ src/share/vm/logging/logFileOutput.hpp
+ src/share/vm/logging/logFileStreamOutput.cpp
+ src/share/vm/logging/logFileStreamOutput.hpp
+ src/share/vm/logging/logLevel.cpp
+ src/share/vm/logging/logLevel.hpp
+ src/share/vm/logging/logOutput.cpp
+ src/share/vm/logging/logOutput.hpp
+ src/share/vm/logging/logOutputList.cpp
+ src/share/vm/logging/logOutputList.hpp
+ src/share/vm/logging/logPrefix.hpp
+ src/share/vm/logging/logTag.cpp
+ src/share/vm/logging/logTag.hpp
+ src/share/vm/logging/logTagLevelExpression.cpp
+ src/share/vm/logging/logTagLevelExpression.hpp
+ src/share/vm/logging/logTagSet.cpp
+ src/share/vm/logging/logTagSet.hpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/nmtCommon.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp
+ test/serviceability/logging/TestBasicLogOutput.java

Changeset: 1f6500dbefcb
Author:    mlarsson
Date:      2015-09-24 16:19 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1f6500dbefcb

Merge


Changeset: 83b9a8e8593d
Author:    mockner
Date:      2015-09-24 11:26 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/83b9a8e8593d

8130681: Kitchensink startup crashes JVM with NMT overlapping ranges
Summary: add_committed_region now handles overlapping commits.
Reviewed-by: hseigel, coleenp

! src/share/vm/services/virtualMemoryTracker.cpp
+ test/runtime/NMT/CommitOverlappingRegions.java

Changeset: f1e0206e75e1
Author:    dsamersoff
Date:      2015-09-24 20:39 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f1e0206e75e1

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

+ test/serviceability/sa/DeadlockDetectionTest.java

Changeset: 4ed0a395857b
Author:    dsamersoff
Date:      2015-09-25 10:21 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4ed0a395857b

Merge


Changeset: d4dec7270392
Author:    kzhaldyb
Date:      2015-09-24 18:48 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d4dec7270392

8136398: Create test that checks that G1 MixedGC produces correct output to logfile
Summary: Added test that checks that G1 MixedGC produces correct output to logfile
Reviewed-by: tschatzl

+ test/gc/g1/mixedgc/TestLogging.java

Changeset: a4ae74ca2403
Author:    brutisso
Date:      2015-09-28 09:28 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a4ae74ca2403

8136991: [REDO] Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125
Reviewed-by: kbarrett, tschatzl

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/shared/gcTraceTime.cpp
! src/share/vm/gc/shared/gcTraceTime.hpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/referenceProcessor.hpp
+ test/gc/logging/TestPrintReferences.java

Changeset: 142f04931a09
Author:    jwilhelm
Date:      2015-09-28 15:05 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/142f04931a09

Merge


Changeset: dc9930a04ab0
Author:    david
Date:      2015-09-29 11:02 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dc9930a04ab0

8080775: Better argument formatting for assert() and friends
Reviewed-by: kbarrett, pliden

! make/linux/makefiles/gcc.make
! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/methodHandles_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/ppc/vm/macroAssembler_ppc.cpp
! src/cpu/ppc/vm/methodHandles_ppc.cpp
! src/cpu/ppc/vm/nativeInst_ppc.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/os/aix/vm/os_aix.cpp
! src/os/aix/vm/vmError_aix.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/vmError_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/vmError_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/threadCritical_solaris.cpp
! src/os/solaris/vm/vmError_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/vmError_windows.cpp
! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp
! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciKlass.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/stringTable.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/gc/cms/adaptiveFreeList.cpp
! src/share/vm/gc/cms/allocationStats.hpp
! src/share/vm/gc/cms/compactibleFreeListSpace.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc/cms/parCardTableModRefBS.cpp
! src/share/vm/gc/cms/promotionInfo.hpp
! src/share/vm/gc/g1/bufferingOopClosure.cpp
! src/share/vm/gc/g1/collectionSetChooser.cpp
! src/share/vm/gc/g1/collectionSetChooser.hpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.inline.hpp
! src/share/vm/gc/g1/g1AllocRegion.cpp
! src/share/vm/gc/g1/g1AllocRegion.hpp
! src/share/vm/gc/g1/g1AllocRegion.inline.hpp
! src/share/vm/gc/g1/g1Allocator.cpp
! src/share/vm/gc/g1/g1Allocator.hpp
! src/share/vm/gc/g1/g1Allocator.inline.hpp
! src/share/vm/gc/g1/g1BiasedArray.cpp
! src/share/vm/gc/g1/g1BiasedArray.hpp
! src/share/vm/gc/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc/g1/g1BlockOffsetTable.hpp
! src/share/vm/gc/g1/g1BlockOffsetTable.inline.hpp
! src/share/vm/gc/g1/g1CardCounts.cpp
! src/share/vm/gc/g1/g1CardCounts.hpp
! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1EvacFailure.cpp
! src/share/vm/gc/g1/g1EvacStats.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc/g1/g1HotCardCache.cpp
! src/share/vm/gc/g1/g1InCSetState.hpp
! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1PageBasedVirtualSpace.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp
! src/share/vm/gc/g1/g1RegionToSpaceMapper.cpp
! src/share/vm/gc/g1/g1RemSet.cpp
! src/share/vm/gc/g1/heapRegion.cpp
! src/share/vm/gc/g1/heapRegion.hpp
! src/share/vm/gc/g1/heapRegion.inline.hpp
! src/share/vm/gc/g1/heapRegionManager.cpp
! src/share/vm/gc/g1/heapRegionManager.inline.hpp
! src/share/vm/gc/g1/heapRegionRemSet.cpp
! src/share/vm/gc/g1/heapRegionSet.cpp
! src/share/vm/gc/g1/heapRegionSet.inline.hpp
! src/share/vm/gc/g1/heapRegionType.hpp
! src/share/vm/gc/g1/satbQueue.cpp
! src/share/vm/gc/g1/vm_operations_g1.cpp
! src/share/vm/gc/parallel/cardTableExtension.cpp
! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/mutableNUMASpace.cpp
! src/share/vm/gc/parallel/objectStartArray.cpp
! src/share/vm/gc/parallel/objectStartArray.hpp
! src/share/vm/gc/parallel/parMarkBitMap.hpp
! src/share/vm/gc/parallel/parallelScavengeHeap.inline.hpp
! src/share/vm/gc/parallel/pcTasks.cpp
! src/share/vm/gc/parallel/psOldGen.hpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/tenuredGeneration.cpp
! src/share/vm/gc/shared/ageTable.cpp
! src/share/vm/gc/shared/blockOffsetTable.cpp
! src/share/vm/gc/shared/cardTableModRefBS.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/collectedHeap.inline.hpp
! src/share/vm/gc/shared/collectorPolicy.cpp
! src/share/vm/gc/shared/gcCause.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/plab.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/space.cpp
! src/share/vm/gc/shared/taskqueue.cpp
! src/share/vm/gc/shared/workgroup.cpp
! src/share/vm/gc/shared/workgroup.hpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/logging/logConfiguration.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/iterator.inline.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspaceGCThresholdUpdater.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/memory/virtualspace.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klass.inline.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/oop.cpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/castnode.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/mathexactnode.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/memprofiler.cpp
! src/share/vm/runtime/mutex.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/chunkedList.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/fakeRttiSupport.hpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: 143fe39b8533
Author:    brutisso
Date:      2015-09-29 17:44 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/143fe39b8533

8133706: Kitchensink hanged
Reviewed-by: pliden, jmasa

! src/share/vm/gc/g1/concurrentMarkThread.cpp

Changeset: 983c56341c80
Author:    brutisso
Date:      2015-09-30 09:07 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/983c56341c80

8134953: Make the GC ID available in a central place
Reviewed-by: pliden, jmasa

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepThread.cpp
! src/share/vm/gc/cms/parNewGeneration.cpp
! src/share/vm/gc/cms/vmCMSOperations.cpp
! src/share/vm/gc/cms/vmCMSOperations.hpp
! src/share/vm/gc/cms/yieldingWorkgroup.cpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.hpp
! src/share/vm/gc/g1/concurrentMarkThread.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1MMUTracker.cpp
! src/share/vm/gc/g1/g1MMUTracker.hpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/g1/vm_operations_g1.cpp
! src/share/vm/gc/g1/vm_operations_g1.hpp
! src/share/vm/gc/parallel/pcTasks.cpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp
! src/share/vm/gc/shared/gcTrace.cpp
! src/share/vm/gc/shared/gcTrace.hpp
! src/share/vm/gc/shared/gcTraceSend.cpp
! src/share/vm/gc/shared/gcTraceTime.cpp
! src/share/vm/gc/shared/gcTraceTime.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/objectCountEventSender.cpp
! src/share/vm/gc/shared/objectCountEventSender.hpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/referenceProcessor.hpp
! src/share/vm/gc/shared/workgroup.cpp
! src/share/vm/gc/shared/workgroup.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp

Changeset: 59e6f265dd40
Author:    aharlap
Date:      2015-09-30 18:09 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/59e6f265dd40

8130265: gctests/LargeObjects/large001 fails with OutOfMemoryError: Java heap space
Summary: Avoided G1 OutOfMemoryError by adding extra expand heap call
Reviewed-by: jwilhelm, tschatzl

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp

Changeset: 43a1e4ca7ee4
Author:    hseigel
Date:      2015-10-01 15:14 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/43a1e4ca7ee4

8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding
Summary: TestBasicLogOutput.java edited to account for padding in tag descriptors
Reviewed-by: ddmitriev, hseigel, coleenp
Contributed-by: rachel.protacio at oracle.com

! test/serviceability/logging/TestBasicLogOutput.java

Changeset: 38bd261644c0
Author:    erikj
Date:      2015-10-02 10:15 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/38bd261644c0

8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx
Reviewed-by: ihse, mikael

! make/bsd/makefiles/jsig.make

Changeset: b04892bbefa5
Author:    david
Date:      2015-10-02 10:43 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b04892bbefa5

8138637: Remove err_msg from LOG_PREFIX macro
Reviewed-by: brutisso

! src/share/vm/logging/logPrefix.hpp

Changeset: c0b0699bf991
Author:    david
Date:      2015-10-02 11:02 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c0b0699bf991

Merge


Changeset: 12a66b77145e
Author:    dcubed
Date:      2015-10-01 13:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/12a66b77145e

8135195: VM Options file should not be limited to 1k in bytes
Summary: Change Arguments::parse_vm_options_file() to remove 1024 byte limit on the VM options file.
Reviewed-by: dcubed, hseigel, gthornbr, dsamersoff, ddmitriev, coleenp

! src/share/vm/runtime/arguments.cpp

Changeset: 6020dab5cdcb
Author:    dcubed
Date:      2015-10-01 13:43 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6020dab5cdcb

8137105: [TESTBUG] Add test cases for VM Options file feature with removed file size limit
Summary: Update TestVMOptionsFile.java to match fix for 8135195; other minor cleanups.
Reviewed-by: dcubed, rdurbin

! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java
! test/runtime/CommandLine/VMOptionsFile/optionfile_1
- test/runtime/CommandLine/VMOptionsFile/optionfile_long_property
! test/runtime/CommandLine/VMOptionsFile/optionfile_lot_of_options_quote
! test/runtime/CommandLine/VMOptionsFile/optionfile_quote
- test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size
- test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property

Changeset: da0795953c69
Author:    dcubed
Date:      2015-10-02 11:58 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/da0795953c69

Merge


Changeset: ccf99d847b02
Author:    dcubed
Date:      2015-10-02 12:44 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ccf99d847b02

Merge

- test/runtime/CommandLine/VMOptionsFile/optionfile_long_property
- test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size
- test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property

Changeset: f5379b29c4d7
Author:    ctornqvi
Date:      2015-10-02 06:06 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f5379b29c4d7

8137194: Exclude runtime/memory/RunUnitTestsConcurrently.java from JPRT
Reviewed-by: coleenp

! test/TEST.groups

Changeset: 0952227d9cfe
Author:    ddmitriev
Date:      2015-10-02 09:04 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0952227d9cfe

8138769: [TESTBUG] restore lost line from JDK-8137105 fix
Reviewed-by: dcubed, rdurbin

! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java

Changeset: 4edb0704e9f3
Author:    dcubed
Date:      2015-10-02 16:48 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4edb0704e9f3

Merge


Changeset: d9d44c9d7bf0
Author:    goetz
Date:      2015-09-28 12:57 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d9d44c9d7bf0

8137260: fix warning after "8046148: JEP 158: Unified JVM Logging"
Reviewed-by: mlarsson, stuefe

! src/share/vm/logging/logFileOutput.cpp

Changeset: 786145ca3cdc
Author:    iklam
Date:      2015-10-05 13:25 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/786145ca3cdc

8078295: hotspot test_env.sh can set VM_CPU incorrectly
Summary: Use sed script to filter out irrelevant parts of -Xinternalversion
Reviewed-by: dlong, dcubed, dsamersoff

! test/test_env.sh

Changeset: f6da147987bb
Author:    kbarrett
Date:      2015-10-05 21:17 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f6da147987bb

8138833: Remove CMMarkStack::drain
Summary: Remove unused functions and data members.
Reviewed-by: pliden, brutisso

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.hpp

Changeset: 231ab9f9a824
Author:    pliden
Date:      2015-10-06 08:05 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/231ab9f9a824

8138846: Remove unused enum ConcurrentGCThread::CGC_flag_type
Reviewed-by: jwilhelm, brutisso

! src/share/vm/gc/shared/concurrentGCThread.cpp
! src/share/vm/gc/shared/concurrentGCThread.hpp

Changeset: 89c745739292
Author:    brutisso
Date:      2015-10-06 14:25 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/89c745739292

8138862: Remove some unused code and subclasses in gcTaskManager.hpp/cpp
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp

Changeset: 4704ecd9e198
Author:    brutisso
Date:      2015-10-06 14:26 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4704ecd9e198

8138863: Refactor WaitForBarrierGCTask
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp

Changeset: 17cfe2c6dc00
Author:    brutisso
Date:      2015-10-06 14:27 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/17cfe2c6dc00

8138707: TestPromotionEventWithParallelScavenge.java crashes using undefined GC id.
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp
! src/share/vm/gc/parallel/gcTaskThread.cpp

Changeset: f10efc097bae
Author:    mockner
Date:      2015-10-06 14:27 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f10efc097bae

8138917: Back out change for 8130681
Summary: Change 8130681 has been backed out.
Reviewed-by: coleenp, gtriantafill

! src/share/vm/services/virtualMemoryTracker.cpp
- test/runtime/NMT/CommitOverlappingRegions.java

Changeset: a6499084ccd4
Author:    coleenp
Date:      2015-10-06 18:51 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a6499084ccd4

Merge


Changeset: 00e5743fd189
Author:    jwilhelm
Date:      2015-10-07 01:03 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/00e5743fd189

Merge

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/runtime/frame.cpp

Changeset: 5f9da6c532fe
Author:    ehelin
Date:      2015-10-07 15:06 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5f9da6c532fe

8138969: G1CollectorPolicy should use const for applicable methods
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
! src/share/vm/gc/g1/g1MMUTracker.hpp

Changeset: 4d9b98fd9644
Author:    david
Date:      2015-10-07 15:27 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4d9b98fd9644

8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated.
Reviewed-by: jwilhelm, mgerdin

! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: c9d09b5085ea
Author:    david
Date:      2015-10-07 14:56 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c9d09b5085ea

Merge


Changeset: 313e94244ed8
Author:    ehelin
Date:      2015-10-07 17:00 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/313e94244ed8

8138971: G1CollectorPolicy::_rs_lengths_prediction is not initialized before use
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/g1/g1CollectorPolicy.cpp

Changeset: 81ae0334f957
Author:    ehelin
Date:      2015-10-07 17:33 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/81ae0334f957

Merge


Changeset: ee11c7701f8c
Author:    gtriantafill
Date:      2015-10-07 11:37 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ee11c7701f8c

8134432: [TESTBUG] Rewrite test/runtime/6888954/vmerrors.sh in Java
Reviewed-by: ddmitriev, ctornqvi, coleenp

! src/share/vm/utilities/debug.cpp
! test/TEST.groups
- test/runtime/6888954/vmerrors.sh
+ test/runtime/ErrorHandling/ErrorHandler.java

Changeset: 4740e6551edf
Author:    ctornqvi
Date:      2015-10-07 20:45 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4740e6551edf

Merge

- test/runtime/6888954/vmerrors.sh

Changeset: 01c086e6e523
Author:    stuefe
Date:      2015-10-01 09:30 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/01c086e6e523

8137329: [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging"
Reviewed-by: simonis, ihse, prr, goetz, dcubed

! src/share/vm/utilities/globalDefinitions_visCPP.hpp

Changeset: 332b3d89d2bd
Author:    dcubed
Date:      2015-10-07 16:41 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/332b3d89d2bd

Merge


Changeset: ad24aa13b296
Author:    dcubed
Date:      2015-10-07 22:54 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ad24aa13b296

Merge


Changeset: a9a4581814a8
Author:    kzhaldyb
Date:      2015-10-07 18:02 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a9a4581814a8

8138958: Quarantine gc/g1/mixedgc/TestLogging.java test
Reviewed-by: brutisso, iignatyev

! test/gc/g1/mixedgc/TestLogging.java

Changeset: e3053e6726f1
Author:    iignatyev
Date:      2015-10-08 01:04 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e3053e6726f1

Merge


Changeset: 17986acb4825
Author:    goetz
Date:      2015-10-02 11:46 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/17986acb4825

8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775
Summary: Also fix one problematic format on ppc.
Reviewed-by: david, simonis

! make/linux/makefiles/gcc.make
! src/cpu/ppc/vm/stubGenerator_ppc.cpp
! src/share/vm/utilities/debug.hpp

Changeset: 371ac7d4ccb2
Author:    ehelin
Date:      2015-10-08 12:47 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/371ac7d4ccb2

8139134: Wrong tenuring threshold in young GC trace event
Reviewed-by: ehelin, jwilhelm
Contributed-by: Carsten Varming <cvarming at twitter.com>

! src/share/vm/gc/cms/parNewGeneration.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp

Changeset: 5459f44b1a75
Author:    sangheki
Date:      2015-10-05 14:56 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5459f44b1a75

8134995: [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
Summary: Add ranges and constraint functions for GC flags.
Reviewed-by: kbarrett, jmasa, jwilhelm, gziemski, zmajo

! src/share/vm/gc/g1/g1_globals.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.hpp
! src/share/vm/runtime/commandLineFlagConstraintsGC.cpp
! src/share/vm/runtime/commandLineFlagConstraintsGC.hpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/globals.hpp
+ test/gc/arguments/TestG1ConcMarkStepDurationMillis.java
! test/gc/arguments/TestG1HeapRegionSize.java
! test/gc/arguments/TestHeapFreeRatio.java
! test/gc/arguments/TestInitialTenuringThreshold.java
! test/gc/arguments/TestObjectTenuringFlags.java
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: 4fa9cbb14029
Author:    jwilhelm
Date:      2015-10-08 22:35 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4fa9cbb14029

Merge


Changeset: e3b180765091
Author:    brutisso
Date:      2015-10-08 12:44 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e3b180765091

8138717: TestGCEventMixedWithG1ConcurrentMark.java fails
Reviewed-by: jwilhelm, david

! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp

Changeset: 0cda477a3c85
Author:    mgerdin
Date:      2015-10-09 09:00 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0cda477a3c85

8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp
Reviewed-by: dcubed, kbarrett, coleenp

! src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp

Changeset: 115188e14c15
Author:    david
Date:      2015-10-09 09:42 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/115188e14c15

8042893: compiler: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files
8042894: runtime: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files
Reviewed-by: goetz, brutisso

! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/stringTable.cpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/icBuffer.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/pcDesc.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/methodLiveness.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/libadt/dict.cpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/virtualspace.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/markOop.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/oop.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/privilegedStack.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/jniHandles.cpp
! src/share/vm/runtime/mutex.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/osThread.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/stackValueCollection.cpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/unhandledOops.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/writeableFlags.cpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: f39faaf2ca61
Author:    david
Date:      2015-10-09 08:46 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f39faaf2ca61

Merge


Changeset: d6c2fafabfb4
Author:    ehelin
Date:      2015-10-09 15:48 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d6c2fafabfb4

8138972: G1CollectorPolicy::_max_survivor_regions should be intialized in the initializer list
Reviewed-by: jwilhelm, mgerdin

! src/share/vm/gc/g1/g1CollectorPolicy.cpp

Changeset: abd2f07dc9fa
Author:    kbarrett
Date:      2015-10-09 14:08 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/abd2f07dc9fa

8138659: Speed up InstanceKlass subclass discrimination
Summary: Add _misc_kind field and flags, move around predicates.
Reviewed-by: coleenp, stefank

! src/share/vm/oops/instanceClassLoaderKlass.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceMirrorKlass.hpp
! src/share/vm/oops/instanceRefKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/prims/jvmtiTagMap.cpp

Changeset: 2ecdb2c2d9be
Author:    brutisso
Date:      2015-10-09 20:31 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2ecdb2c2d9be

8139293: TestGCEventMixedWithG1ConcurrentMark.java fails after JDK-8134953
Reviewed-by: ecaspole, jwilhelm

! src/share/vm/gc/g1/concurrentMarkThread.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp

Changeset: 05b4a6f553fc
Author:    brutisso
Date:      2015-10-09 20:52 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/05b4a6f553fc

8139294: TestGCEventMixedWithCMSConcurrent.java still fails after JDK-8134953
Reviewed-by: jwilhelm, ecaspole

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp

Changeset: dd72902de3dc
Author:    brutisso
Date:      2015-10-09 20:45 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dd72902de3dc

Merge


Changeset: 53c5cb9d3fed
Author:    jwilhelm
Date:      2015-10-15 13:28 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/53c5cb9d3fed

Merge

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp

Changeset: 263abae1965e
Author:    thartmann
Date:      2015-10-08 08:54 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/263abae1965e

8139048: Quarantine compiler/startup/SmallCodeCacheStartup.java
Summary: Quarantine the test because it fails on JPRT for the CPU, CompactStrings and JVMCI repositories.
Reviewed-by: roland

! test/compiler/startup/SmallCodeCacheStartup.java

Changeset: f4f0e306133e
Author:    thartmann
Date:      2015-10-08 07:51 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f4f0e306133e

Merge


Changeset: 09fb2c936faa
Author:    zmajo
Date:      2015-10-08 12:10 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/09fb2c936faa

8137160: Use Compile::live_nodes instead of Compile::unique() in appropriate places -- followup
Summary: Change two code locations to use live_nodes() instead of unique() for allocating memory. Adjust comments.
Reviewed-by: kvn

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/matcher.cpp

Changeset: 0011fab3f1b5
Author:    zmajo
Date:      2015-10-08 10:25 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0011fab3f1b5

Merge


Changeset: a41fe5ffa839
Author:    twisti
Date:      2015-10-08 12:49 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a41fe5ffa839

8136421: JEP 243: Java-Level JVM Compiler Interface
Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett

! make/bsd/makefiles/compiler1.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/minimal1.make
! make/excludeSrc.make
+ make/gensrc/Gensrc-jdk.vm.ci.gmk
! make/linux/makefiles/compiler1.make
! make/linux/makefiles/minimal1.make
! make/solaris/makefiles/compiler1.make
! make/windows/build_vm_def.sh
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make
! src/cpu/aarch64/vm/compiledIC_aarch64.cpp
! src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp
! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
+ src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp
! src/cpu/aarch64/vm/relocInfo_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp
! src/cpu/ppc/vm/compiledIC_ppc.cpp
+ src/cpu/ppc/vm/jvmciCodeInstaller_ppc.cpp
! src/cpu/ppc/vm/relocInfo_ppc.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/compiledIC_sparc.cpp
! src/cpu/sparc/vm/cppInterpreterGenerator_sparc.hpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
+ src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.hpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/sparc/vm/vmStructs_sparc.hpp
! src/cpu/sparc/vm/vm_version_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/cpu/x86/vm/compiledIC_x86.cpp
! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/interp_masm_x86.cpp
! src/cpu/x86/vm/interp_masm_x86.hpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
+ src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.hpp
+ src/cpu/x86/vm/registerMap_x86.cpp
! src/cpu/x86/vm/registerMap_x86.hpp
! src/cpu/x86/vm/register_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86.cpp
! src/cpu/x86/vm/vmStructs_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/x86/vm/x86_64.ad
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/overview.html
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/AbstractAddress.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Architecture.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BailoutException.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodePosition.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CallingConvention.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeCacheProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompilationResult.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DataSection.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DebugInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InfopointReason.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InstalledCode.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InvalidInstalledCodeException.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Location.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/MemoryBarriers.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ReferenceMap.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Register.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterAttributes.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterSaveLayout.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/SourceStackTrace.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackLockValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlot.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlotValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/TargetDescription.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/UnsignedMath.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ValueUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualObject.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualStackSlot.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/package-info.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrame.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrameVisitor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/JVMCIError.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/UnsafeUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/Compiler.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/CompilerFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/StartupEventListener.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotRegisterConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotJVMCIBackendFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotRegisterConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledCode.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompressedNullConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotForeignCallTarget.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotInstalledCode.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIMetaAccessContext.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntimeProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodData.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodUnresolved.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotNmethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotOopMap.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProxified.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotReferenceMap.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSentinelConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSignature.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotStackFrameReference.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigVerifier.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMEventListener.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVmSymbols.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/MetaspaceWrapperObject.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/Stable.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SuppressFBWarnings.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/UnsafeAccess.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EmptyEventProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EventProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/logging/package-info.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMAddress.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMData.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMFlag.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMManual.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.inittimer/src/jdk/vm/ci/inittimer/InitTimer.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.inittimer/src/jdk/vm/ci/inittimer/SuppressFBWarnings.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/overview.html
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AbstractJavaProfile.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AbstractProfiledItem.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AllocatableValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Assumptions.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Constant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantPool.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantReflectionProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DefaultProfilingInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationAction.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationReason.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ExceptionHandler.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/InvokeTarget.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JVMCIMetaAccessContext.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaKind.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethodProfile.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaTypeProfile.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LIRKind.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LineNumberTable.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LineNumberTableImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Local.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTable.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTableImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocationIdentity.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MemoryAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MethodHandleAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ModifiersProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/NullConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PlatformKind.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PrimitiveConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ProfilingInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/RawConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SerializableConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Signature.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SpeculationLog.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/TriState.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/TrustedInterface.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/VMConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Value.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/package-info.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/META-INF/services/javax.annotation.processing.Processor
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/jdk/vm/ci/options/processor/OptionProcessor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/DerivedOptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/JVMCIJarsOptionDescriptorsProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/NestedBooleanOptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/Option.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionDescriptor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionDescriptors.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsLoader.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsParser.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/StableOptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIBackend.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIRuntime.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/META-INF/services/javax.annotation.processing.Processor
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/jdk/vm/ci/service/processor/ServiceProviderProcessor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/ServiceProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/Services.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARC.java
+ src/os/aix/vm/vmStructs_aix.hpp
+ src/os/bsd/vm/vmStructs_bsd.hpp
+ src/os/linux/vm/vmStructs_linux.hpp
+ src/os/solaris/vm/vmStructs_solaris.hpp
! src/os/windows/vm/os_windows.cpp
+ src/os/windows/vm/vmStructs_windows.hpp
! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/compiledIC.hpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/debugInfoRec.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/dependencies.hpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/exceptionHandlerTable.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/oopRecorder.cpp
! src/share/vm/code/oopRecorder.hpp
! src/share/vm/code/pcDesc.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/scopeDesc.hpp
! src/share/vm/compiler/abstractCompiler.cpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileTask.cpp
! src/share/vm/compiler/compileTask.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp
! src/share/vm/gc/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/barrierSet.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/collectedHeap.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
+ src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp
+ src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp
+ src/share/vm/jvmci/jvmciCodeInstaller.cpp
+ src/share/vm/jvmci/jvmciCodeInstaller.hpp
+ src/share/vm/jvmci/jvmciCompiler.cpp
+ src/share/vm/jvmci/jvmciCompiler.hpp
+ src/share/vm/jvmci/jvmciCompilerToVM.cpp
+ src/share/vm/jvmci/jvmciCompilerToVM.hpp
+ src/share/vm/jvmci/jvmciEnv.cpp
+ src/share/vm/jvmci/jvmciEnv.hpp
+ src/share/vm/jvmci/jvmciJavaClasses.cpp
+ src/share/vm/jvmci/jvmciJavaClasses.hpp
+ src/share/vm/jvmci/jvmciRuntime.cpp
+ src/share/vm/jvmci/jvmciRuntime.hpp
+ src/share/vm/jvmci/jvmci_globals.cpp
+ src/share/vm/jvmci/jvmci_globals.hpp
+ src/share/vm/jvmci/systemDictionary_jvmci.hpp
+ src/share/vm/jvmci/vmStructs_jvmci.hpp
+ src/share/vm/jvmci/vmSymbols_jvmci.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/superword.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/javaCalls.hpp
! src/share/vm/runtime/rframe.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/timer.cpp
! src/share/vm/runtime/timer.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vmStructs.hpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/shark/sharkCacheDecache.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/fakeRttiSupport.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/growableArray.hpp
! src/share/vm/utilities/macros.hpp
! src/share/vm/utilities/top.hpp
! src/share/vm/utilities/vmError.cpp
+ test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java
+ test/compiler/jvmci/SecurityRestrictionsTest.java
+ test/compiler/jvmci/common/CTVMUtilities.java
+ test/compiler/jvmci/common/CompilerToVMHelper.java
+ test/compiler/jvmci/common/JVMCIHelpers.java
+ test/compiler/jvmci/common/services/jdk.vm.ci.compiler.Compiler
+ test/compiler/jvmci/common/services/jdk.vm.ci.compiler.CompilerFactory
+ test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.HotSpotVMEventListener
+ test/compiler/jvmci/common/testcases/AbstractClass.java
+ test/compiler/jvmci/common/testcases/AbstractClassExtender.java
+ test/compiler/jvmci/common/testcases/AnotherSingleImplementer.java
+ test/compiler/jvmci/common/testcases/AnotherSingleImplementerInterface.java
+ test/compiler/jvmci/common/testcases/DoNotExtendClass.java
+ test/compiler/jvmci/common/testcases/DoNotImplementInterface.java
+ test/compiler/jvmci/common/testcases/MultiSubclassedClass.java
+ test/compiler/jvmci/common/testcases/MultiSubclassedClassSubclass1.java
+ test/compiler/jvmci/common/testcases/MultiSubclassedClassSubclass2.java
+ test/compiler/jvmci/common/testcases/MultipleAbstractImplementer.java
+ test/compiler/jvmci/common/testcases/MultipleImplementer1.java
+ test/compiler/jvmci/common/testcases/MultipleImplementer2.java
+ test/compiler/jvmci/common/testcases/MultipleImplementersInterface.java
+ test/compiler/jvmci/common/testcases/MultipleImplementersInterfaceExtender.java
+ test/compiler/jvmci/common/testcases/PackagePrivateClass.java
+ test/compiler/jvmci/common/testcases/SimpleClass.java
+ test/compiler/jvmci/common/testcases/SingleImplementer.java
+ test/compiler/jvmci/common/testcases/SingleImplementerInterface.java
+ test/compiler/jvmci/common/testcases/SingleSubclass.java
+ test/compiler/jvmci/common/testcases/SingleSubclassedClass.java
+ test/compiler/jvmci/common/testcases/TestCase.java
+ test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java
+ test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java
+ test/compiler/jvmci/compilerToVM/CollectCountersTest.java
+ test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java
+ test/compiler/jvmci/compilerToVM/ConstantPoolTestCase.java
+ test/compiler/jvmci/compilerToVM/ConstantPoolTestsHelper.java
+ test/compiler/jvmci/compilerToVM/DebugOutputTest.java
+ test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java
+ test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java
+ test/compiler/jvmci/compilerToVM/DummyAbstractClass.java
+ test/compiler/jvmci/compilerToVM/DummyClass.java
+ test/compiler/jvmci/compilerToVM/DummyInterface.java
+ test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java
+ test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java
+ test/compiler/jvmci/compilerToVM/GetBytecodeTest.java
+ test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java
+ test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java
+ test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java
+ test/compiler/jvmci/compilerToVM/GetImplementorTest.java
+ test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java
+ test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java
+ test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java
+ test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java
+ test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java
+ test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java
+ test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java
+ test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java
+ test/compiler/jvmci/compilerToVM/GetSymbolTest.java
+ test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java
+ test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java
+ test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java
+ test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java
+ test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java
+ test/compiler/jvmci/compilerToVM/IsMatureTest.java
+ test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java
+ test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java
+ test/compiler/jvmci/compilerToVM/LookupTypeTest.java
+ test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
+ test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java
+ test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java
+ test/compiler/jvmci/compilerToVM/ReprofileTest.java
+ test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java
+ test/compiler/jvmci/compilerToVM/ResolveMethodTest.java
+ test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java
+ test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java
+ test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java
+ test/compiler/jvmci/events/JvmciCompleteInitializationTest.config
+ test/compiler/jvmci/events/JvmciCompleteInitializationTest.java
+ test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.config
+ test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java
+ test/compiler/jvmci/events/JvmciNotifyInstallEventTest.config
+ test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java
+ test/compiler/jvmci/events/JvmciShutdownEventListener.java
+ test/compiler/jvmci/events/JvmciShutdownEventTest.config
+ test/compiler/jvmci/events/JvmciShutdownEventTest.java
+ test/compiler/jvmci/events/MetaAccessWrapper.java
+ test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/NestedBooleanOptionValueTest.java
+ test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/TestOptionValue.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/FieldUniverse.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/MethodUniverse.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/NameAndSignature.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TypeUniverse.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 13c4fa17712e
Author:    dlong
Date:      2015-10-09 02:43 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/13c4fa17712e

Merge

! src/cpu/x86/vm/templateInterpreter_x86_32.cpp

Changeset: 926d9bae67d3
Author:    thartmann
Date:      2015-10-09 11:28 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/926d9bae67d3

8139150: ClassVerifier frees exception message while it's still in use
Summary: Remove ResourceMark in StackMapReader::parse_verification_type() to avoid freeing of error message.
Reviewed-by: zmajo, dcubed, hseigel

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

Changeset: 0300297e7df3
Author:    zmajo
Date:      2015-10-09 14:21 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0300297e7df3

8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing
Summary: Add range check or constraint where necessary.
Reviewed-by: roland, thartmann

! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/oops/methodCounters.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp
! src/share/vm/runtime/globals.hpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java
! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java

Changeset: 71e75172487b
Author:    zmajo
Date:      2015-10-09 15:00 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/71e75172487b

8081288: erronous free in RegClass::~RegClass()
Summary: Remove the erronous free.
Reviewed-by: kvn

! src/share/vm/adlc/formsopt.cpp

Changeset: 6c4a9b1af999
Author:    twisti
Date:      2015-10-09 09:09 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6c4a9b1af999

8138820: JDK Hotspot build fails with Xcode 7.0.1
Reviewed-by: iveresov

! make/bsd/makefiles/gcc.make

Changeset: a37a6ca422b1
Author:    iveresov
Date:      2015-10-09 12:17 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a37a6ca422b1

8136725: Provide utility for creation a counted loop reserve copy (clone)
Summary: Make it easier to revert to the original loop should that be needed
Reviewed-by: kvn
Contributed-by: jan.civlin at intel.com

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp

Changeset: dda16b631985
Author:    iveresov
Date:      2015-10-09 21:04 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dda16b631985

Merge


Changeset: de73f59378c1
Author:    redestad
Date:      2015-10-12 14:54 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/de73f59378c1

8134607: Remove per-compiler performance counters
Reviewed-by: twisti, neliasso

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp

Changeset: 1f0d9d89003a
Author:    iveresov
Date:      2015-10-12 16:35 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1f0d9d89003a

8139454: java/lang/Math/WorstCaseTests.java crashes on Linux-amd64
Summary: Emit the form of pextrw that works with sse2
Reviewed-by: iveresov, twisti
Contributed-by: vivek.r.deshpande at intel.com

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: c6a1e7983723
Author:    mdoerr
Date:      2015-10-12 12:20 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c6a1e7983723

8139421: PPC64LE: MacroAssembler::bxx64_patchable kill register R12
Summary: Register R12 must be preserved for stub calls (e.g. deopt handler).
Reviewed-by: goetz

! src/cpu/ppc/vm/macroAssembler_ppc.cpp

Changeset: 7477b0afa5d6
Author:    zmajo
Date:      2015-10-13 10:09 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7477b0afa5d6

8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth
Summary: Raise upper bound of TypeProfileWidth from 4 to 8.
Reviewed-by: iveresov, twisti

! src/share/vm/runtime/globals.hpp

Changeset: 738f57684fed
Author:    enevill
Date:      2015-10-13 09:40 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/738f57684fed

8139259: aarch64: jtreg test TestLogSum segvs after 8132207
Summary: Fix jump to 0 caused by uninitialised _dexp in 8132207
Reviewed-by: roland, kvn

! src/share/vm/opto/library_call.cpp

Changeset: f2983a0f7a57
Author:    roland
Date:      2015-10-13 13:23 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f2983a0f7a57

Merge


Changeset: 2598332ad46c
Author:    aph
Date:      2015-09-30 13:23 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2598332ad46c

8138641: Disable C2 peephole by default for aarch64
Reviewed-by: roland
Contributed-by: felix.yang at linaro.org

! src/cpu/aarch64/vm/c2_globals_aarch64.hpp

Changeset: 0ca52fb7d980
Author:    aph
Date:      2015-09-29 17:01 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0ca52fb7d980

8138575: Improve generated code for profile counters
Reviewed-by: kvn

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp

Changeset: 870c2e0f67f6
Author:    enevill
Date:      2015-10-08 13:14 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/870c2e0f67f6

8139043: aarch64: add support for adler32 intrinsic
Summary: Add adler32 support like 8132081 for sparc
Reviewed-by: kvn

! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! src/cpu/aarch64/vm/vm_version_aarch64.cpp

Changeset: c274072ab8f7
Author:    twisti
Date:      2015-10-13 09:21 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c274072ab8f7

8139524: JVMCI cannot be initialized with CMS or Serial GCs
Reviewed-by: iveresov

! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: d9eb619390d9
Author:    twisti
Date:      2015-10-14 09:22 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d9eb619390d9

8139545: JVMCI : guarantee(heap_end < allocation_end) failed on some sparcv9 hosts
Reviewed-by: iveresov, kvn

! src/share/vm/jvmci/jvmciRuntime.cpp

Changeset: 78888d676ed7
Author:    twisti
Date:      2015-10-14 12:29 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/78888d676ed7

8139386: JVMCI test failed with assert(_jvmci._alternate_call_target == 0L) failed: must be
Reviewed-by: kvn

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp

Changeset: baccb954c369
Author:    roland
Date:      2015-10-15 09:40 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/baccb954c369

8138956: Elide more final field's write memory barrier with escape analysis result
Summary: membar for final/stable fields eliminated if possible
Reviewed-by: roland, mdoerr, enevill, aph
Contributed-by: hui.shi at linaro.org

! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse3.cpp

Changeset: 9ab5571ccea8
Author:    roland
Date:      2015-10-15 07:56 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9ab5571ccea8

Merge


Changeset: db88a5e95717
Author:    iignatyev
Date:      2015-10-13 16:21 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/db88a5e95717

8139376: [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9
Reviewed-by: twisti, kvn

! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java

Changeset: ceec25b3f949
Author:    tpivovarova
Date:      2015-10-15 01:58 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ceec25b3f949

8139375: [TESTBUG] compiler/jvmci/SecurityRestrictionsTest checks are too tight
Reviewed-by: twisti, iignatyev

! test/compiler/jvmci/SecurityRestrictionsTest.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: acf9f6650193
Author:    dpochepk
Date:      2015-10-15 02:46 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/acf9f6650193

8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization
Reviewed-by: iignatyev, twisti

! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java

Changeset: 964538c2362a
Author:    iignatyev
Date:      2015-10-15 09:36 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/964538c2362a

Merge


Changeset: 2abd2feb000b
Author:    iignatyev
Date:      2015-10-15 11:20 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2abd2feb000b

Merge


Changeset: e9fede3afe79
Author:    kshefov
Date:      2015-10-15 18:00 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e9fede3afe79

8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests
Reviewed-by: twisti, kvn, iignatyev, tpivovarova

! test/compiler/c2/5057225/Test5057225.java
! test/compiler/c2/6603011/Test.java
! test/compiler/c2/6800154/Test6800154.java
! test/compiler/c2/6805724/Test6805724.java
! test/compiler/codegen/6823354/Test6823354.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: cf43bef12125
Author:    zmajo
Date:      2015-10-15 17:38 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cf43bef12125

8080650: Enable stubs to use frame pointers correctly
Summary: Change MacroAssembler::verified_entry() to set up RBP correctly when generating stub code.
Reviewed-by: kvn

! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad

Changeset: e012dfc7ba2c
Author:    zmajo
Date:      2015-10-15 17:40 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e012dfc7ba2c

Merge


Changeset: 6bef5a526bee
Author:    iignatyev
Date:      2015-10-16 01:15 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6bef5a526bee

8138794: [TESTBUG] ctw tests fail to compile after 8137056
Reviewed-by: dlong, kvn

! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java

Changeset: fe46f2941ea9
Author:    iignatyev
Date:      2015-10-16 02:05 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/fe46f2941ea9

8139707: [TESTBUG] Quarantine unstable compiler/jvmci tests
Reviewed-by: twisti

! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java
! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java
! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java

Changeset: 41b06143f4f8
Author:    enevill
Date:      2015-10-15 15:33 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/41b06143f4f8

8139674: aarch64: guarantee failure in TestOptionsWithRanges.java
Summary: Fix negative overflow in instruction field
Reviewed-by: kvn, roland, adinn, aph

! src/cpu/aarch64/vm/interp_masm_aarch64.cpp

Changeset: 93ae449c9b52
Author:    aph
Date:      2015-10-13 16:25 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/93ae449c9b52

8139041: Redundant DMB instructions
Summary: Merge consecutive DMB intstructions
Reviewed-by: roland, kvn, twisti

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! src/cpu/aarch64/vm/nativeInst_aarch64.hpp
! src/share/vm/asm/codeBuffer.hpp

Changeset: 5ffaf14b397d
Author:    roland
Date:      2015-10-16 11:47 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5ffaf14b397d

Merge


Changeset: bfd1cd5fbb7c
Author:    zmajo
Date:      2015-10-16 15:21 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bfd1cd5fbb7c

8139380: VMError::report_and_die() does not produce replay file
Summary: Change VMError::report() to use a correct format string in both JVMCI-enabled builds and builds without JVMCI.
Reviewed-by: roland, kvn

! src/share/vm/utilities/vmError.cpp

Changeset: 09338e9e661c
Author:    roland
Date:      2015-10-16 15:48 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/09338e9e661c

8139750: [BACKOUT] Elide more final field's write memory barrier with escape analysis result
Reviewed-by: kvn

! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse3.cpp

Changeset: 179aa0067f01
Author:    roland
Date:      2015-10-16 16:09 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/179aa0067f01

Merge


Changeset: a8a8604f890f
Author:    dlong
Date:      2015-10-17 19:40 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a8a8604f890f

Merge

! make/windows/makefiles/vm.make
! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! src/cpu/ppc/vm/macroAssembler_ppc.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
+ src/share/vm/jvmci/jvmciCodeInstaller.cpp
+ src/share/vm/jvmci/jvmciJavaClasses.cpp
+ src/share/vm/jvmci/jvmciJavaClasses.hpp
+ src/share/vm/jvmci/jvmciRuntime.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/fakeRttiSupport.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/vmError.cpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: 846276b97202
Author:    amurillo
Date:      2015-10-19 12:30 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/846276b97202

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: 4be1d228e368
Author:    twisti
Date:      2015-10-21 11:41 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4be1d228e368

8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes
Reviewed-by: erikj

! make/gensrc/Gensrc-jdk.vm.ci.gmk

Changeset: e197d5a708f1
Author:    lana
Date:      2015-10-21 18:39 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e197d5a708f1

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: 1904cb079212
Author:    lana
Date:      2015-10-22 11:13 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1904cb079212

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: 2bc339eaafcd
Author:    david
Date:      2015-10-13 08:37 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2bc339eaafcd

8139427: Break out YoungList to own class.
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
+ src/share/vm/gc/g1/youngList.cpp
+ src/share/vm/gc/g1/youngList.hpp

Changeset: 8b8a3e7af130
Author:    tschatzl
Date:      2015-10-13 14:49 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8b8a3e7af130

8069330: Adjustment of concurrent refinement thresholds does not take hot card cache into account
Summary: Measure HCC processing time separately and remove that time from the calculation of the refinement thresholds. HCC processing time is still taken into account for general pause time predictions.
Reviewed-by: tbenson, jmasa

! src/share/vm/gc/g1/concurrentG1Refine.hpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1ErgoVerbose.cpp
! src/share/vm/gc/g1/g1ErgoVerbose.hpp
! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc/g1/g1HotCardCache.cpp
! src/share/vm/gc/g1/g1HotCardCache.hpp
! src/share/vm/gc/g1/g1RemSet.cpp
! test/gc/g1/TestGCLogMessages.java

Changeset: 3417a8fa7b45
Author:    david
Date:      2015-10-13 14:07 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3417a8fa7b45

8139506: Remove the WaterMark class
Reviewed-by: stefank, mgerdin

! src/share/vm/gc/g1/heapRegion.hpp
! src/share/vm/gc/shared/generation.hpp
! src/share/vm/gc/shared/space.cpp
! src/share/vm/gc/shared/space.hpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b7618d69edaf
Author:    david
Date:      2015-10-13 17:34 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b7618d69edaf

Merge

- src/share/vm/gc/shared/watermark.hpp

Changeset: c8a4fbc7f6f4
Author:    hseigel
Date:      2015-10-14 13:30 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c8a4fbc7f6f4

8139069: JVM should throw ClassFormatError for <init> methods in interfaces
Summary: If method being parsed is in an interface, throw ClassFormatError if its name is "<init>"
Reviewed-by: acorn, lfoltan

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/verifier.cpp
+ test/runtime/classFileParserBug/InitInInterface.java
+ test/runtime/classFileParserBug/nonvoidinit.jasm
+ test/runtime/classFileParserBug/voidinit.jasm

Changeset: 088ca8a0e910
Author:    poonam
Date:      2015-10-14 15:36 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/088ca8a0e910

8136577: Make AbortVMOnException available in product builds
Reviewed-by: coleenp

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp

Changeset: bc00f9701b9c
Author:    minqi
Date:      2015-10-14 08:12 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/bc00f9701b9c

8135284: Remove Method::_method_size field
Summary: Remove Method::_method_size to improve memory footprint after JDK-8135085,which increased 4 bytes for 32 platform. Also removed related unused code in SA.
Reviewed-by: coleenp, hseigel

! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 5a7f73370cf8
Author:    minqi
Date:      2015-10-14 20:59 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5a7f73370cf8

Merge


Changeset: 1d78034f1852
Author:    minqi
Date:      2015-10-15 00:42 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1d78034f1852

Merge


Changeset: 8c666050d769
Author:    david
Date:      2015-10-14 09:33 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8c666050d769

8139434: Unify GenRemSet and CardTableRS
Reviewed-by: jwilhelm, mgerdin

! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/serial/tenuredGeneration.cpp
! src/share/vm/gc/serial/tenuredGeneration.hpp
! src/share/vm/gc/shared/cardGeneration.cpp
! src/share/vm/gc/shared/cardGeneration.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/cardTableRS.hpp
! src/share/vm/gc/shared/collectorPolicy.cpp
! src/share/vm/gc/shared/collectorPolicy.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.hpp
! src/share/vm/gc/shared/genOopClosures.inline.hpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
! src/share/vm/gc/shared/generation.cpp
! src/share/vm/gc/shared/generation.hpp
! src/share/vm/gc/shared/generationSpec.cpp
! src/share/vm/gc/shared/generationSpec.hpp
! src/share/vm/gc/shared/space.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 5f32f22ba25e
Author:    mgerdin
Date:      2015-10-14 14:50 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5f32f22ba25e

8138762: Refactor setup of evacuation closures in G1
Summary: Introduce policy class containing the root scan closures.
Reviewed-by: ehelin, stefank

! src/share/vm/gc/g1/g1CodeBlobClosure.hpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/g1/g1OopClosures.inline.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1RemSet.cpp
! src/share/vm/gc/g1/g1RemSet.hpp
+ src/share/vm/gc/g1/g1RootClosures.cpp
+ src/share/vm/gc/g1/g1RootClosures.hpp
! src/share/vm/gc/g1/g1RootProcessor.cpp
! src/share/vm/gc/g1/g1RootProcessor.hpp

Changeset: 5b33eeb13775
Author:    tschatzl
Date:      2015-10-15 10:07 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5b33eeb13775

8137082: Factor out G1 prediction code from G1CollectorPolicy and clean up
Summary: Factor out G1 prediction code from G1CollectorPolicy into its own class, constify methods of G1CollectorPolicy and move more implementations to the cpp file.
Reviewed-by: jmasa, sangheki, ecaspole, kbarrett

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
+ src/share/vm/gc/g1/g1Predictions.cpp
+ src/share/vm/gc/g1/g1Predictions.hpp
! src/share/vm/gc/g1/survRateGroup.cpp
! src/share/vm/gc/g1/survRateGroup.hpp
! src/share/vm/prims/jni.cpp

Changeset: 2feeca2b688f
Author:    tschatzl
Date:      2015-10-15 10:12 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2feeca2b688f

8139583: Fix formatting in survRateGroup.cpp
Reviewed-by: kbarrett, stefank

! src/share/vm/gc/g1/survRateGroup.cpp

Changeset: daa76166601c
Author:    tschatzl
Date:      2015-10-15 10:13 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/daa76166601c

8138750: Remove dead code in survivor rate group
Reviewed-by: mgerdin, tbenson

! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
! src/share/vm/gc/g1/survRateGroup.cpp
! src/share/vm/gc/g1/survRateGroup.hpp

Changeset: a0f7fb36730a
Author:    tschatzl
Date:      2015-10-15 10:15 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a0f7fb36730a

8138752: G1CollectorPolicy::should_should_update_surv_rate_group_predictors() uses wrong predicate
Summary: Instead of only updating the survivor rate groups in the young gc after marking and before mixed gc, update them during young gcs outside of marking
Reviewed-by: mgerdin, drwhite

! src/share/vm/gc/g1/g1CollectorPolicy.hpp

Changeset: 47181fafd4e9
Author:    tschatzl
Date:      2015-10-15 13:00 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/47181fafd4e9

Merge

! src/share/vm/gc/g1/g1CollectorPolicy.cpp

Changeset: 901d0ab08236
Author:    jbachorik
Date:      2015-10-15 17:35 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/901d0ab08236

8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized
Reviewed-by: dcubed, martin

+ test/serviceability/dcmd/gc/FinalizationRunner.java
! test/serviceability/dcmd/gc/RunFinalizationTest.java

Changeset: 1a85bb362183
Author:    dcubed
Date:      2015-10-15 10:00 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1a85bb362183

8136552: Last argument wins does not work for special options with "-XX:VMOptionsFile" option
Summary: match_special_option_and_act() should insert_vm_options_file() earlier and process the inserted options right away to honor "last option wins" semantics.
Reviewed-by: dcubed, coleenp

! src/share/vm/runtime/arguments.cpp
! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java

Changeset: cdd81465ef70
Author:    dcubed
Date:      2015-10-15 19:17 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cdd81465ef70

Merge


Changeset: 3f28db271235
Author:    gziemski
Date:      2015-10-15 13:34 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3f28db271235

8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing.
Summary: JEP 245: implement ranges and constraints for runtime flags.
Reviewed-by: coleenp, ddmitriev, jiangli, goetz
Contributed-by: goetz.lindenmaier at sap.com, gerard.ziemski at oracle.com

! src/cpu/aarch64/vm/globals_aarch64.hpp
! src/cpu/ppc/vm/globals_ppc.hpp
! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/zero/vm/globals_zero.hpp
! src/os/aix/vm/globals_aix.hpp
! src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.hpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/vmThread.cpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: db268cb78542
Author:    coleenp
Date:      2015-10-16 00:01 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/db268cb78542

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 01b171218ecd
Author:    kbarrett
Date:      2015-10-15 10:10 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/01b171218ecd

8139200: Eliminate G1ParClosureSuper::_worker_id
Summary: Moved _worker_id from G1ParClosureSuper to G1ParCopyHelper.
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/g1/g1OopClosures.inline.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp

Changeset: 09c316072f18
Author:    mdoerr
Date:      2015-10-16 10:20 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/09c316072f18

8139734: ppc: fix build after "8078556: Runtime: implement ranges..."
Reviewed-by: goetz

! src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp

Changeset: a014961e513b
Author:    kbarrett
Date:      2015-10-16 14:55 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a014961e513b

8139341: Hide ExtendedOopClosure::_ref_processor
Summary: Make ExtendedOopClosure::_ref_processor private.
Reviewed-by: mgerdin, sjohanss

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/serial/markSweep.hpp
! src/share/vm/gc/shared/genOopClosures.hpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/oops/instanceRefKlass.inline.hpp

Changeset: e70a21e29520
Author:    david
Date:      2015-10-16 14:11 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e70a21e29520

8139277: Remove ScavengeWithObjectsInToSpace, ParallelOldGCSplitALot, ParallelOldGCSplitInterval, PSAdjustTenuredGenForMinorPause and PSAdjustYoungGenForMajorPause
Reviewed-by: tschatzl, sjohanss

! src/share/vm/gc/parallel/psAdaptiveSizePolicy.cpp
! src/share/vm/gc/parallel/psAdaptiveSizePolicy.hpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psParallelCompact.hpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: ec3193176165
Author:    ehelin
Date:      2015-10-19 15:21 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ec3193176165

8135078: Refactor InCSetState::is_in_cset_or_humongous
Reviewed-by: tschatzl, jwilhelm

! src/share/vm/gc/g1/g1InCSetState.hpp

Changeset: 9b74c5f1b10e
Author:    brutisso
Date:      2015-10-20 14:00 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9b74c5f1b10e

8139868: CMSScavengeBeforeRemark broken after JDK-8134953
Reviewed-by: sjohanss, jwilhelm

! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
+ test/gc/cms/TestCMSScavengeBeforeRemark.java

Changeset: 29c399fbbf25
Author:    jprovino
Date:      2015-10-20 11:17 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/29c399fbbf25

Merge

! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/exceptions.cpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: 6bea4fdaae80
Author:    amurillo
Date:      2015-10-22 16:25 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6bea4fdaae80

Merge

- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp

Changeset: 20dff0211ded
Author:    mgerdin
Date:      2015-10-26 17:13 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/20dff0211ded

8140452: Internal Error memory/allocation.cpp:179
Summary: use const ref & and avoid copy ctor
Reviewed-by: coleenp

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp

Changeset: 7fe46dc64bb3
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7fe46dc64bb3

Added tag jdk9-b89 for changeset 20dff0211ded

! .hgtags

Changeset: 3fd5c2ca4c20
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3fd5c2ca4c20

Added tag jdk9-b90 for changeset 7fe46dc64bb3

! .hgtags

Changeset: 2760de77e5c5
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2760de77e5c5

Added tag jdk9-b91 for changeset 3fd5c2ca4c20

! .hgtags

Changeset: f5112887ebd7
Author:    vlivanov
Date:      2015-09-06 10:13 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f5112887ebd7

8065151: Support IdealGraphVisualizer in optimized build
Reviewed-by: kvn

! src/share/vm/opto/c2_globals.hpp

Changeset: 420908d02f8d
Author:    erikj
Date:      2015-10-20 10:24 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/420908d02f8d

8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file
Reviewed-by: twisti

! make/gensrc/Gensrc-jdk.vm.ci.gmk

Changeset: 9108fab781a4
Author:    roland
Date:      2015-10-16 16:53 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9108fab781a4

8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI
Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods
Reviewed-by: kvn, thartmann

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
+ test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java

Changeset: eb7736a32a0f
Author:    roland
Date:      2015-10-20 13:36 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/eb7736a32a0f

Merge


Changeset: a176d4737606
Author:    neliasso
Date:      2015-10-20 18:07 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a176d4737606

8137167: JEP165: Compiler Control: Implementation task
Summary: Compiler Control JEP
Reviewed-by: roland, twisti, zmajo, simonis

! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_Compiler.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileTask.cpp
+ src/share/vm/compiler/compilerDirectives.cpp
+ src/share/vm/compiler/compilerDirectives.hpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
+ src/share/vm/compiler/directivesParser.cpp
+ src/share/vm/compiler/directivesParser.hpp
! src/share/vm/compiler/methodMatcher.cpp
! src/share/vm/compiler/methodMatcher.hpp
! src/share/vm/jvmci/jvmciCompiler.cpp
! src/share/vm/jvmci/jvmciCompiler.hpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/c2compiler.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/idealGraphPrinter.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkCompiler.hpp
+ src/share/vm/utilities/json.cpp
+ src/share/vm/utilities/json.hpp
+ test/compiler/compilercontrol/InlineMatcherTest.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java
+ test/compiler/compilercontrol/control_off.txt
+ test/compiler/compilercontrol/control_on.txt
+ test/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java
+ test/serviceability/dcmd/compiler/control1.txt
+ test/serviceability/dcmd/compiler/control2.txt

Changeset: 535c335eb11c
Author:    ppunegov
Date:      2015-10-20 21:09 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/535c335eb11c

8066153: JEP-JDK-8046155: Test task: cover existing
Summary: Tests for CompilerCommand and CompilerControl's directives
Reviewed-by: kvn

+ test/compiler/compilercontrol/commandfile/CompileOnlyTest.java
+ test/compiler/compilercontrol/commandfile/ExcludeTest.java
+ test/compiler/compilercontrol/commandfile/LogTest.java
+ test/compiler/compilercontrol/commandfile/PrintTest.java
+ test/compiler/compilercontrol/commands/CompileOnlyTest.java
+ test/compiler/compilercontrol/commands/ExcludeTest.java
+ test/compiler/compilercontrol/commands/LogTest.java
+ test/compiler/compilercontrol/commands/PrintTest.java
+ test/compiler/compilercontrol/directives/CompileOnlyTest.java
+ test/compiler/compilercontrol/directives/ExcludeTest.java
+ test/compiler/compilercontrol/directives/LogTest.java
+ test/compiler/compilercontrol/directives/PrintTest.java
+ test/compiler/compilercontrol/mixed/RandomCommandsTest.java
+ test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java
+ test/compiler/compilercontrol/share/AbstractTestBase.java
+ test/compiler/compilercontrol/share/JSONFile.java
+ test/compiler/compilercontrol/share/MultiCommand.java
+ test/compiler/compilercontrol/share/SingleCommand.java
+ test/compiler/compilercontrol/share/actions/BaseAction.java
+ test/compiler/compilercontrol/share/actions/CompileAction.java
! test/compiler/compilercontrol/share/method/MethodGenerator.java
! test/compiler/compilercontrol/share/method/SignatureType.java
+ test/compiler/compilercontrol/share/processors/CommandProcessor.java
+ test/compiler/compilercontrol/share/processors/LogProcessor.java
+ test/compiler/compilercontrol/share/processors/PrintProcessor.java
+ test/compiler/compilercontrol/share/processors/QuietProcessor.java
+ test/compiler/compilercontrol/share/scenario/AbstractCommandBuilder.java
+ test/compiler/compilercontrol/share/scenario/Command.java
+ test/compiler/compilercontrol/share/scenario/CommandFileBuilder.java
+ test/compiler/compilercontrol/share/scenario/CommandGenerator.java
+ test/compiler/compilercontrol/share/scenario/CommandOptionsBuilder.java
+ test/compiler/compilercontrol/share/scenario/CompileCommand.java
+ test/compiler/compilercontrol/share/scenario/DirectiveBuilder.java
+ test/compiler/compilercontrol/share/scenario/DirectiveWriter.java
+ test/compiler/compilercontrol/share/scenario/Scenario.java

Changeset: 11c3bed1e41e
Author:    ppunegov
Date:      2015-10-20 21:12 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/11c3bed1e41e

8066166: JEP-JDK-8046155: Test task: dcmd tests
Summary: Tests for diagnostic command in CompilerControl
Reviewed-by: kvn

+ test/compiler/compilercontrol/jcmd/AddAndRemoveTest.java
+ test/compiler/compilercontrol/jcmd/AddCompileOnlyTest.java
+ test/compiler/compilercontrol/jcmd/AddExcludeTest.java
+ test/compiler/compilercontrol/jcmd/AddLogTest.java
+ test/compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java
+ test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java
+ test/compiler/compilercontrol/jcmd/ClearDirectivesStackTest.java
! test/compiler/compilercontrol/share/scenario/CommandGenerator.java
+ test/compiler/compilercontrol/share/scenario/JcmdCommand.java
+ test/compiler/compilercontrol/share/scenario/JcmdStateBuilder.java
! test/compiler/compilercontrol/share/scenario/Scenario.java

Changeset: 1cd251540653
Author:    vlivanov
Date:      2015-10-20 19:22 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1cd251540653

8132168: Support IdealGraphVisualizer in optimized build
Reviewed-by: kvn

! src/share/vm/opto/c2_globals.hpp

Changeset: 03fa0a35a468
Author:    vlivanov
Date:      2015-10-20 22:03 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/03fa0a35a468

Merge

! src/share/vm/opto/c2_globals.hpp

Changeset: 111d1c4c90e7
Author:    goetz
Date:      2015-10-21 18:22 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/111d1c4c90e7

8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build"
Reviewed-by: vlivanov

! src/share/vm/compiler/compilerDirectives.hpp

Changeset: 713aa577bd38
Author:    neliasso
Date:      2015-10-21 19:31 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/713aa577bd38

8140240: Missing test files in CompilerControl tests
Summary: Add missing files
Reviewed-by: kvn, neliasso

+ test/compiler/compilercontrol/share/scenario/State.java
+ test/compiler/compilercontrol/share/scenario/StateBuilder.java
! test/testlibrary/jdk/test/lib/ProcessTools.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: a60bd3d34158
Author:    neliasso
Date:      2015-10-21 21:59 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a60bd3d34158

Merge


Changeset: d80d1084cfdc
Author:    dlong
Date:      2015-10-21 18:05 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d80d1084cfdc

8140267: assert(is_native_ptr || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown
Summary: back out 8136473
Reviewed-by: twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
- test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java

Changeset: ffae03d59aa9
Author:    dlong
Date:      2015-10-21 18:34 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ffae03d59aa9

Merge


Changeset: ea9eaad05466
Author:    enevill
Date:      2015-10-21 12:15 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ea9eaad05466

8140238: Zero fails to build from source
Summary: Zero fails to build after 8136421 and 8078554
Reviewed-by: kvn

! src/cpu/zero/vm/compiledIC_zero.cpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/vm_version_zero.cpp

Changeset: a0c5acb7c322
Author:    mdoerr
Date:      2015-10-09 20:58 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a0c5acb7c322

8138890: C1: Ambiguous operator delete
Summary: xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification
Reviewed-by: simonis, goetz, twisti

! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_RangeCheckElimination.hpp

Changeset: 5dc1db0a5290
Author:    twisti
Date:      2015-10-21 21:49 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5dc1db0a5290

Merge


Changeset: cc7b816cca18
Author:    twisti
Date:      2015-10-22 19:03 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/cc7b816cca18

Merge


Changeset: 4b46d2b42fcb
Author:    iveresov
Date:      2015-10-22 21:39 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4b46d2b42fcb

8139575: Update for x86 log in the math lib
Summary: Add new java.lang.Math() intrinsics from x86
Reviewed-by: kvn, iveresov
Contributed-by: vivek.r.deshpande at intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86_libm.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: d9315ec5c471
Author:    twisti
Date:      2015-10-22 13:18 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d9315ec5c471

8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug
Reviewed-by: erikj, kvn

! make/bsd/makefiles/gcc.make
! make/linux/makefiles/gcc.make
! make/solaris/makefiles/gcc.make
! src/share/vm/runtime/vmStructs.cpp

Changeset: e32667cd477c
Author:    twisti
Date:      2015-10-23 07:18 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e32667cd477c

Merge

! src/share/vm/runtime/vmStructs.cpp

Changeset: 5d13c9b094c4
Author:    neliasso
Date:      2015-10-26 10:36 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5d13c9b094c4

8139996: CompileCommand prints quoted ascii strings
Summary: Print symbols as utf8
Reviewed-by: kvn

! src/share/vm/compiler/methodMatcher.cpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp

Changeset: ae64ff428e18
Author:    iveresov
Date:      2015-10-26 19:33 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ae64ff428e18

8139340: SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu
Summary: Emit vector conditional moves
Reviewed-by: kvn
Contributed-by: jan.civlin at intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: e7b4c40ebb11
Author:    dlong
Date:      2015-10-27 01:45 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e7b4c40ebb11

Merge

! make/gensrc/Gensrc-jdk.vm.ci.gmk
! src/share/vm/c1/c1_Runtime1.cpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 0ecd612047de
Author:    enevill
Date:      2015-10-27 10:08 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0ecd612047de

8140582: aarch64: jvm fails to initialise after 8078556
Summary: jvm fails to initialise on aarch64 systems with pagesize > 4K
Reviewed-by: duke

! src/cpu/aarch64/vm/globals_aarch64.hpp

Changeset: 427a91c68b67
Author:    enevill
Date:      2015-10-27 18:05 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/427a91c68b67

8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs
Summary: Fix register usage on calling native synchronized methods
Reviewed-by: kvn, adinn

! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: 9c4989b6889a
Author:    zmajo
Date:      2015-10-28 15:15 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9c4989b6889a

8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout
Summary: Change MontgomeryMultiplyTest.java test to execute only on platforms on which the tested intrinsics are available.
Reviewed-by: kvn, neliasso

! test/compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java

Changeset: ea4fcd70985d
Author:    ppunegov
Date:      2015-10-28 16:00 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ea4fcd70985d

8140350: compiler control tests fail with compiled: true,  but should: false on required level: 1
Summary: Replace isMethodCompiled with isMethodCompilable with particular level
Reviewed-by: kvn

! test/compiler/compilercontrol/share/actions/CompileAction.java

Changeset: 48b73c88892f
Author:    ppunegov
Date:      2015-10-28 16:26 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/48b73c88892f

8140453: compiler control test failed with RuntimeException: CompileCommand: nonexistent missing
Summary: Replace incorrect check for validity of method pattern with full command check
Reviewed-by: kvn

! test/compiler/compilercontrol/share/processors/CommandProcessor.java
! test/compiler/compilercontrol/share/processors/QuietProcessor.java

Changeset: 4883b314d4b9
Author:    ppunegov
Date:      2015-10-28 16:38 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4883b314d4b9

8066158: JEP-JDK-8046155: Test task: directive parser
Summary: check directive file parser with correct and incorrect files
Reviewed-by: kvn

+ test/compiler/compilercontrol/parser/DirectiveParser.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 0b2937220009
Author:    iignatyev
Date:      2015-10-28 16:01 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0b2937220009

Merge


Changeset: 96bcdd3a6e79
Author:    neliasso
Date:      2015-10-28 15:44 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/96bcdd3a6e79

8140581: Excluding compile messages should only be printed with PrintCompilation
Summary: Use PrintCompilation flag instead
Reviewed-by: kvn

! src/share/vm/compiler/compileBroker.cpp

Changeset: 0fa6910c516d
Author:    neliasso
Date:      2015-10-23 10:57 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0fa6910c516d

8140343: SEGV in DirectivesStack::getMatchingDirective
Summary: Could not match JVMCI compiler
Reviewed-by: kvn

! src/share/vm/compiler/compilerDirectives.cpp

Changeset: 1d49bd532a6f
Author:    zmajo
Date:      2015-10-29 09:24 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1d49bd532a6f

8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly
Summary: Improve parsing of DisableIntrinsic flag.
Reviewed-by: kvn, shade, neliasso

! src/share/vm/compiler/compilerDirectives.cpp
! src/share/vm/compiler/compilerDirectives.hpp
! src/share/vm/compiler/directivesParser.cpp
! src/share/vm/compiler/directivesParser.hpp
+ test/compiler/intrinsics/IntrinsicDisabledTest.java

Changeset: b62347567e9b
Author:    ppunegov
Date:      2015-10-29 01:16 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b62347567e9b

8140668: Quarantine RandomValidCommandsTest
8140669: Quarantine ClearDirectivesFileStackTest
Summary: Quarantine two tests
Reviewed-by: iignatyev, neliasso, kvn

! test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java
! test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java

Changeset: e18469511c58
Author:    iignatyev
Date:      2015-10-29 10:56 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e18469511c58

Merge


Changeset: 0835ef4e6232
Author:    shade
Date:      2015-10-29 14:08 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0835ef4e6232

8140483: Atomic*FieldUpdaters final fields should be trusted
Summary: Add exceptions for A*FU subclasses that do the actual work.
Reviewed-by: jrose, vlivanov

! src/share/vm/ci/ciField.cpp
! src/share/vm/classfile/vmSymbols.hpp

Changeset: 7fb261378480
Author:    shade
Date:      2015-10-29 13:23 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7fb261378480

Merge


Changeset: e3690e58d28e
Author:    iveresov
Date:      2015-10-29 09:59 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e3690e58d28e

8140604: Internal Error runtime/stubRoutines.hpp:392 assert(_intrinsic_log != 0L) failed: must be defined
Summary: Fix the faulty assert, remove remaining _intrinsic_log references
Reviewed-by: roland

! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp

Changeset: b03c5e9f24ba
Author:    ppunegov
Date:      2015-10-29 21:31 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b03c5e9f24ba

8140776: CompilerControl: Remove UTF-16 from the tests
Summary: remove UTF-16 from the generation until the failure reason isn't found
Reviewed-by: iignatyev

! test/compiler/compilercontrol/share/method/MethodGenerator.java

Changeset: 8c85cc5c9fb8
Author:    iignatyev
Date:      2015-10-29 19:30 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8c85cc5c9fb8

Merge


Changeset: 79b56d21b736
Author:    amurillo
Date:      2015-10-30 12:03 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/79b56d21b736

Merge


Changeset: 53cb98d68a1a
Author:    lana
Date:      2015-11-05 13:41 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/53cb98d68a1a

Merge


Changeset: 8fd684b8c649
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8fd684b8c649

Added tag jdk9-b92 for changeset 53cb98d68a1a

! .hgtags

Changeset: 029a2b20b570
Author:    stefank
Date:      2015-10-13 10:06 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/029a2b20b570

8058563: InstanceKlass::_dependencies list isn't cleared from empty nmethodBucket entries
Reviewed-by: mgerdin, vlivanov

! src/share/vm/code/nmethod.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/prims/jni.cpp

Changeset: 85a63e83293f
Author:    ecaspole
Date:      2015-10-20 14:01 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/85a63e83293f

8060017: G1: Report heap sizing time
Summary: Report heap expansion time done on VM thread after collection. Previously this was included in "Other" time.
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.hpp
! test/gc/g1/TestGCLogMessages.java

Changeset: dcf365644bef
Author:    ecaspole
Date:      2015-10-20 22:35 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dcf365644bef

Merge

! src/share/vm/gc/g1/g1CollectedHeap.cpp

Changeset: a4281fe5f387
Author:    ecaspole
Date:      2015-10-21 13:46 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a4281fe5f387

Merge

! src/share/vm/gc/g1/g1CollectedHeap.cpp

Changeset: c8afe5c4e9c2
Author:    jwilhelm
Date:      2015-10-19 15:03 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c8afe5c4e9c2

8139772: Cleanups in Generation related code
Reviewed-by: tbenson, mgerdin

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/tenuredGeneration.hpp
! src/share/vm/gc/shared/cardGeneration.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.hpp
! src/share/vm/gc/shared/generation.cpp
! src/share/vm/gc/shared/generation.hpp

Changeset: d83a5e8e97aa
Author:    ctornqvi
Date:      2015-10-21 09:47 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d83a5e8e97aa

8140243: [TESTBUG] Exclude compiler/jvmci/compilerToVM/GetConstantPoolTest.java
Reviewed-by: gtriantafill, kvn

! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java

Changeset: 6f0961ba54bb
Author:    ctornqvi
Date:      2015-10-21 19:10 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6f0961ba54bb

Merge


Changeset: f108f239ffcf
Author:    bobv
Date:      2015-10-19 13:21 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f108f239ffcf

8136556: Add the ability to perform static builds of MacOSX x64 binaries
Reviewed-by: ihse, bdelsart, gadams, lfoltan, rriggs, hseigel, twisti

! make/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jsig.make
! make/bsd/makefiles/rules.make
! make/bsd/makefiles/saproc.make
! make/bsd/makefiles/vm.make
! src/os/bsd/vm/os_bsd.cpp
! src/share/vm/compiler/disassembler.cpp

Changeset: 29f6b9d0f929
Author:    bobv
Date:      2015-10-19 15:48 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/29f6b9d0f929

Merge


Changeset: aa0f8afe2943
Author:    bobv
Date:      2015-10-21 16:38 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/aa0f8afe2943

Merge

! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jsig.make
! src/os/bsd/vm/os_bsd.cpp
! src/share/vm/compiler/disassembler.cpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp
- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: f6f813ccdde7
Author:    bobv
Date:      2015-10-21 17:16 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f6f813ccdde7

Merge


Changeset: 1e70b7cb4cb3
Author:    david
Date:      2015-10-22 08:53 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1e70b7cb4cb3

8139952: Remove UseCMSAdaptiveFreeLists, UseAsyncConcMarkSweepGC, CMSDictionaryChoice, CMSOverflowEarlyRestoration and CMSTestInFreeList
Reviewed-by: jwilhelm, ecaspole

! src/share/vm/gc/cms/compactibleFreeListSpace.cpp
! src/share/vm/gc/cms/compactibleFreeListSpace.hpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc/cms/vmCMSOperations.hpp
! src/share/vm/gc/shared/generationSpec.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 5aba3631c8c0
Author:    ehelin
Date:      2015-10-21 13:41 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5aba3631c8c0

8139256: Add Makefile target to run internal VM tests
Reviewed-by: ihse, erikj

! test/Makefile

Changeset: 825cee2cd7a6
Author:    goetz
Date:      2015-10-22 13:07 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/825cee2cd7a6

8139040: Fix initializations before ShouldNotReachHere() etc. and enable -Wuninitialized on linux.
Reviewed-by: stuefe, coleenp, roland

! agent/src/os/linux/symtab.c
! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/jniFastGetField_x86_32.cpp
! src/cpu/x86/vm/jniFastGetField_x86_64.cpp
! src/os/linux/vm/os_linux.cpp
! src/os_cpu/linux_x86/vm/copy_linux_x86.inline.hpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/compactHashtable.cpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/heapRegionRemSet.cpp
! src/share/vm/gc/g1/heapRegionRemSet.hpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/services/threadService.hpp

Changeset: 96d9c10f256b
Author:    coleenp
Date:      2015-10-22 17:24 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/96d9c10f256b

Merge

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 4b28e0afd0c0
Author:    ehelin
Date:      2015-10-20 14:37 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4b28e0afd0c0

8138975: G1CollectorPolicy::calculate_young_list_target_length should be const
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp

Changeset: 0314c31d9c3e
Author:    gziemski
Date:      2015-10-23 11:17 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0314c31d9c3e

8129855: "-XX:+IgnoreUnrecognizedVMOptions" hides out of range VM options.
Summary: Implement strict spec rgarding how IgnoreUnrecognizedVMOptions works, supplied with the corresponding test case.
Reviewed-by: dcubed, ddmitriev

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! test/compiler/membars/DekkerTest.java
+ test/runtime/CommandLine/IgnoreUnrecognizedVMOptions.java

Changeset: 6ab7e19c9220
Author:    coleenp
Date:      2015-10-23 16:48 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6ab7e19c9220

8140274: methodHandles and constantPoolHandles should be passed as const references
Summary: modified code to use const reference parameters
Reviewed-by: sspitsyn, twisti

! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/os/aix/vm/os_aix.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_Compiler.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/resolutionErrors.cpp
! src/share/vm/classfile/resolutionErrors.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/verifier.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/compiledIC.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/debugInfoRec.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileTask.cpp
! src/share/vm/compiler/compileTask.hpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
! src/share/vm/compiler/methodMatcher.cpp
! src/share/vm/compiler/methodMatcher.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/bytecode.hpp
! src/share/vm/interpreter/bytecodeStream.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/bytecodeTracer.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/jvmci/jvmciCompilerToVM.cpp
! src/share/vm/jvmci/jvmciCompilerToVM.hpp
! src/share/vm/jvmci/jvmciEnv.cpp
! src/share/vm/jvmci/jvmciEnv.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp
! src/share/vm/oops/fieldInfo.hpp
! src/share/vm/oops/fieldStreams.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/generateOopMap.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/c2compiler.hpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/nativeLookup.hpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/advancedThresholdPolicy.hpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/javaCalls.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/reflection.hpp
! src/share/vm/runtime/relocator.cpp
! src/share/vm/runtime/relocator.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/signature.hpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.hpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkCompiler.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp

Changeset: f8ad4efb6be8
Author:    coleenp
Date:      2015-10-23 23:06 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f8ad4efb6be8

Merge

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: a0c7a69277da
Author:    dcubed
Date:      2015-10-24 15:44 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a0c7a69277da

8047212: runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid
Summary: Fix race between ObjectMonitor alloc and verification code; teach SA about "static pointer volatile" fields.
Reviewed-by: cvarming, dholmes, sspitsyn, coleenp

! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/synchronizer.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 4bf6d3c2c816
Author:    dholmes
Date:      2015-10-25 19:19 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4bf6d3c2c816

8134642: ParkEvent::RawThreadIdentity appears to be unused and should be removed
Reviewed-by: dcubed, hseigel

! src/share/vm/runtime/park.hpp

Changeset: 4d7995577f52
Author:    mchernov
Date:      2015-10-23 14:33 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4d7995577f52

8139903: G1EvacStats does not split log entries.
Summary: Added gclog_or_tty->cr() to G1EvacStats to avoid concatenated PLAB log entries.
Reviewed-by: tschatzl, dfazunen

! src/share/vm/gc/g1/g1EvacStats.cpp

Changeset: 714c9bead5bb
Author:    drwhite
Date:      2015-10-21 14:13 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/714c9bead5bb

8140251: Define the G1 term MMU somewhere in the source code.
Summary: (MINOR) Simple comment fix to define Minimum Mutator Utilization (MMU)
Reviewed-by: jwilhelm

! src/share/vm/gc/g1/g1MMUTracker.hpp

Changeset: 834a43b2db17
Author:    aharlap
Date:      2015-10-22 11:33 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/834a43b2db17

8139664: Delete ConcurrentMarkSweepThread::is_ConcurrentGC_thread()
Summary: Remove virtual  method with same implementation as on base class
Reviewed-by: pliden, drwhite

! src/share/vm/gc/cms/concurrentMarkSweepThread.hpp

Changeset: 0aa8adafb982
Author:    sangheki
Date:      2015-10-26 08:34 -0700
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/0aa8adafb982

8139801: Error message from validation check has wrong order on Windows
Summary: Added flushing stdout and stderr before exit or abort
Reviewed-by: coleenp, cjplummer

! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/java.cpp

Changeset: 2c30539cb670
Author:    coleenp
Date:      2015-10-26 18:27 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2c30539cb670

Merge


Changeset: c8434ad4f332
Author:    coleenp
Date:      2015-10-26 13:11 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c8434ad4f332

8139163: InstanceKlass::cast passes through NULL
Summary: Reduce raw (InstanceKlass*) casts and InstanceKlass::cast, which no long allows null
Reviewed-by: twisti, kbarrett

! src/cpu/aarch64/vm/methodHandles_aarch64.cpp
! src/cpu/ppc/vm/methodHandles_ppc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/ci/ciInstanceKlass.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/classfile/bytecodeAssembler.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/dictionary.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/heapRegion.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/jvmci/jvmciCompiler.cpp
! src/share/vm/jvmci/jvmciJavaClasses.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/utilities/exceptions.cpp

Changeset: 78fcf4f320c2
Author:    coleenp
Date:      2015-10-26 20:07 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/78fcf4f320c2

Merge


Changeset: eb05a697271f
Author:    goetz
Date:      2015-10-09 16:39 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/eb05a697271f

8139116: Fixes for warning "format not a string literal"
Reviewed-by: ddmitriev, david, simonis

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/writeableFlags.cpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/xmlstream.cpp

Changeset: f22aeb038230
Author:    tschatzl
Date:      2015-10-27 11:44 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f22aeb038230

8140583: Without PrintPLAB, there are superfluous newlines in the GC log messages
Summary: Conditionalize offending newlines by -XX:+PrintPLAB
Reviewed-by: mgerdin

! src/share/vm/gc/g1/g1EvacStats.cpp

Changeset: 9319d5be1bfb
Author:    chegar
Date:      2015-10-27 14:18 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9319d5be1bfb

8139891: Prepare Unsafe for true encapsulation
Reviewed-by: alanb, dholmes, jrose, psandoz, twisti

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/shark/sharkIntrinsics.cpp
! test/compiler/unsafe/UnsafeGetConstantField.java

Changeset: f27912435e2f
Author:    chegar
Date:      2015-10-27 15:09 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f27912435e2f

Merge


Changeset: c664861faadc
Author:    drwhite
Date:      2015-10-26 12:22 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c664861faadc

8138920: Refactor the sampling thread from ConcurrentG1RefineThread
Summary: Helps enable running without concurrent refinement threads
Reviewed-by: brutisso, pliden

! src/share/vm/gc/g1/concurrentG1Refine.cpp
! src/share/vm/gc/g1/concurrentG1Refine.hpp
! src/share/vm/gc/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc/g1/concurrentG1RefineThread.hpp
! src/share/vm/gc/g1/concurrentMarkThread.cpp
! src/share/vm/gc/g1/concurrentMarkThread.hpp
+ src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp
+ src/share/vm/gc/g1/g1YoungRemSetSamplingThread.hpp
! src/share/vm/gc/shared/concurrentGCThread.cpp

Changeset: 80023d1b61e3
Author:    mgerdin
Date:      2015-10-14 14:51 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/80023d1b61e3

8139149: Split G1 evacuate_collection_set into multiple steps
Reviewed-by: ehelin, tschatzl

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp

Changeset: 33773c9db7b8
Author:    ddmitriev
Date:      2015-10-27 14:33 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/33773c9db7b8

8139900: [TESTBUG] Remove G1UpdateBufferSize and InitialBootClassLoaderMetaspaceSize from TestOptionsWithRanges
Reviewed-by: gziemski, sangheki, ctornqvi

! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java

Changeset: 4535697211eb
Author:    coleenp
Date:      2015-10-28 09:47 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4535697211eb

8139203: Consistent naming for klass type predicates
8138923: Remove oop coupling with InstanceKlass subclasses
Summary: Renamed oop_is_instance and friends, removed the functions in oop that dug down into InstanceKlass.
Reviewed-by: jrose, lfoltan, stefank

! src/share/vm/ci/ciArrayKlass.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciType.cpp
! src/share/vm/ci/ciTypeArrayKlass.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/loaderConstraints.cpp
! src/share/vm/classfile/placeholders.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/dependencies.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/parallel/psCompactionManager.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/jvmci/jvmciCompilerToVM.cpp
! src/share/vm/jvmci/jvmciEnv.cpp
! src/share/vm/jvmci/jvmciRuntime.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.inline.hpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klass.inline.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/oop.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/serviceUtil.hpp

Changeset: 5451df1520e3
Author:    coleenp
Date:      2015-10-28 15:03 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5451df1520e3

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/services/heapDumper.cpp

Changeset: c4aa3283f983
Author:    coleenp
Date:      2015-10-28 16:36 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c4aa3283f983

Merge


Changeset: 86c144769ef4
Author:    dsamersoff
Date:      2015-10-28 21:47 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/86c144769ef4

8140663: FrameValue might be used uninitialized
Summary: Add a constructor
Reviewed-by: sspitsyn, jwilhelm

! src/share/vm/runtime/frame.hpp

Changeset: 3c97451c88ca
Author:    dsamersoff
Date:      2015-10-28 19:54 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/3c97451c88ca

Merge


Changeset: ed89ad123a4e
Author:    gziemski
Date:      2015-10-28 09:09 -0500
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ed89ad123a4e

8140539: compiler/membars/DekkerTest.java fails with -XX:CICompilerCount=1
Summary: Add back "-XX:+IgnoreUnrecognizedVMOptions" that was removed in a prototype.
Reviewed-by: dcubed, ddmitriev

! test/compiler/membars/DekkerTest.java
! test/runtime/CommandLine/IgnoreUnrecognizedVMOptions.java

Changeset: ab480d51b045
Author:    coleenp
Date:      2015-10-28 20:30 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ab480d51b045

Merge


Changeset: f29bfadf2027
Author:    coleenp
Date:      2015-10-28 23:29 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f29bfadf2027

Merge


Changeset: ca77238d7b73
Author:    dsamersoff
Date:      2015-10-28 18:20 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ca77238d7b73

8139762: Format warnings in libjvm_db.c
Summary: Fix format string
Reviewed-by: sspitsyn

! src/os/bsd/dtrace/libjvm_db.c
! src/os/solaris/dtrace/libjvm_db.c

Changeset: 2a6d30096770
Author:    dsamersoff
Date:      2015-10-28 16:45 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2a6d30096770

Merge


Changeset: 978ced4575b1
Author:    dsamersoff
Date:      2015-10-29 02:38 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/978ced4575b1

Merge


Changeset: dd6639e96520
Author:    ehelin
Date:      2015-10-29 11:33 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dd6639e96520

8140761: Remove caching from WorkerDataArray
Reviewed-by: tschatzl, mgerdin, tbenson

! src/share/vm/gc/g1/g1GCPhaseTimes.cpp

Changeset: 9c3631bf7c4b
Author:    ehelin
Date:      2015-10-29 14:58 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9c3631bf7c4b

8140393: Move WorkerDataArray to its own file
Reviewed-by: tschatzl, mgerdin, tbenson

! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
+ src/share/vm/gc/g1/workerDataArray.cpp
+ src/share/vm/gc/g1/workerDataArray.hpp
+ src/share/vm/gc/g1/workerDataArray.inline.hpp
! src/share/vm/prims/jni.cpp

Changeset: 110260436fc6
Author:    ehelin
Date:      2015-10-29 17:32 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/110260436fc6

8140489: Introduce shorthand for average_time_ms in G1CollectorPolicy
Reviewed-by: mgerdin, tschatzl, drwhite

! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp

Changeset: 97a7ba9f10cf
Author:    jwilhelm
Date:      2015-10-30 00:02 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/97a7ba9f10cf

Merge

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp

Changeset: e33baf2cad34
Author:    jwilhelm
Date:      2015-11-05 19:31 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e33baf2cad34

Merge

! make/bsd/makefiles/gcc.make
! make/linux/makefiles/gcc.make
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_Compiler.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileTask.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
! src/share/vm/compiler/methodMatcher.cpp
! src/share/vm/compiler/methodMatcher.hpp
! src/share/vm/jvmci/jvmciCompiler.cpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/c2compiler.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkCompiler.hpp

Changeset: 78430b058a05
Author:    aph
Date:      2015-11-02 12:34 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/78430b058a05

8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049
Summary: nextPutIndex used where nextGetIndex is correct.
Reviewed-by: alanb

! test/compiler/intrinsics/unsafe/HeapByteBufferTest.java

Changeset: f31349f1215e
Author:    thartmann
Date:      2015-11-03 09:41 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f31349f1215e

8141132: JEP 254: Compact Strings
Summary: Adopt a more space-efficient internal representation for strings.
Reviewed-by: alanb, bdelsart, coleenp, iklam, jiangli, jrose, kevinw, naoto, pliden, roland, smarks, twisti
Contributed-by: Brent Christian <brent.christian at oracle.com>, Vivek Deshpande <vivek.r.deshpande at intel.com>, Tobias Hartmann <tobias.hartmann at oracle.com>, Charlie Hunt <charlie.hunt at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, Roger Riggs <roger.riggs at oracle.com>, Xueming Shen <xueming.shen at oracle.com>, Aleksey Shipilev <aleksey.shipilev at oracle.com>, Sandhya Viswanathan <sandhya.viswanathan at intel.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp
! src/cpu/aarch64/vm/globals_aarch64.hpp
! src/cpu/ppc/vm/globals_ppc.hpp
! src/cpu/ppc/vm/ppc.ad
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/cpu/zero/vm/globals_zero.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/main.cpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/ci/ciTypeArray.cpp
! src/share/vm/ci/ciTypeArray.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/stringTable.cpp
! src/share/vm/classfile/stringTable.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/gc/g1/g1StringDedupTable.cpp
! src/share/vm/gc/g1/g1StringDedupTable.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/typeArrayOop.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/intrinsicnode.cpp
! src/share/vm/opto/intrinsicnode.hpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/stringopts.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/utf8.cpp
! src/share/vm/utilities/utf8.hpp
+ test/compiler/intrinsics/string/TestStringIntrinsics.java
+ test/runtime/Annotations/TestAnnotatedStringEncoding.java
+ test/runtime/SharedArchiveFile/CdsDifferentCompactStrings.java

Changeset: caa57b4b87f8
Author:    tpivovarova
Date:      2015-11-03 20:12 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/caa57b4b87f8

8138809: improve tests for CompilerToVM::hasCompiledCodeForOSR
Reviewed-by: kvn

! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java

Changeset: e677ebf4b028
Author:    ppunegov
Date:      2015-11-03 18:42 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e677ebf4b028

8141129: 3 compiler control tests fail on product builds
Summary: UnlockDiagnosticVMOptions should be placed before the PrintAssembly
Reviewed-by: kvn

! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java
! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java
! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java

Changeset: c3abbf1a6f38
Author:    kshefov
Date:      2015-11-03 20:12 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c3abbf1a6f38

8139385: [TESTBUG]: JVMCI test crashes in constantPoolHandle::constantPoolHandle
Reviewed-by: kvn, iignatyev

! src/share/vm/prims/whitebox.cpp

Changeset: 40bd4478a362
Author:    twisti
Date:      2015-11-04 07:23 -1000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/40bd4478a362

8139170: JVMCI refresh
Reviewed-by: kvn

! .hgignore
! make/gensrc/Gensrc-jdk.vm.ci.gmk
! src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp
! src/cpu/ppc/vm/jvmciCodeInstaller_ppc.cpp
! src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/vmStructs_sparc.hpp
! src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp
! src/cpu/x86/vm/vmStructs_x86.hpp
! src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64Kind.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/AbstractAddress.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Architecture.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BailoutException.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodePosition.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CallingConvention.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeCacheProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompilationRequest.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompilationResult.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DataSection.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DebugInfo.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InstalledCode.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Location.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Register.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterAttributes.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterConfig.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterSaveLayout.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterValue.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/SourceStackTrace.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackLockValue.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlot.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlotValue.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/TargetDescription.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/UnsignedMath.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ValueUtil.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualObject.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualStackSlot.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/package-info.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrame.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/JVMCIError.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/Compiler.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/CompilerFactory.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/StartupEventListener.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotRegisterConfig.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotJVMCIBackendFactory.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotRegisterConfig.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompilationRequest.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledCode.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompressedNullConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotInstalledCode.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIMetaAccessContext.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntimeProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJavaType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaAccessProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethod.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodData.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodUnresolved.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotNmethod.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotOopMap.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotReferenceMap.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaField.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotRuntimeStub.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSentinelConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSignature.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotStackFrameReference.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotStackIntrospection.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedField.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedJavaType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigVerifier.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMEventListener.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVmSymbols.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/MetaspaceWrapperObject.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/Stable.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SuppressFBWarnings.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EmptyEventProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMAddress.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMData.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMField.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMFlag.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMManual.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Assumptions.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantReflectionProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DefaultProfilingInfo.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ExceptionHandler.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JVMCIMetaAccessContext.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaField.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaKind.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethod.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethodProfile.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaTypeProfile.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LIRKind.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTableImpl.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocationIdentity.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaAccessProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MethodHandleAccessProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ModifiersProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PlatformKind.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PrimitiveConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaField.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaType.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SerializableConstant.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SpeculationLog.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/jdk/vm/ci/options/processor/OptionProcessor.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/DerivedOptionValue.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/JVMCIJarsOptionDescriptorsProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/NestedBooleanOptionValue.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/Option.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionValue.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsLoader.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsParser.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIBackend.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCICompiler.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCICompilerFactory.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIRuntime.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/jdk/vm/ci/service/processor/ServiceProviderProcessor.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml
! src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/ServiceProvider.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/Services.java
! src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARC.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java
! src/os/solaris/vm/os_solaris.inline.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/jvmci/jvmciCodeInstaller.cpp
! src/share/vm/jvmci/jvmciCodeInstaller.hpp
! src/share/vm/jvmci/jvmciCompiler.cpp
! src/share/vm/jvmci/jvmciCompiler.hpp
! src/share/vm/jvmci/jvmciCompilerToVM.cpp
! src/share/vm/jvmci/jvmciCompilerToVM.hpp
! src/share/vm/jvmci/jvmciEnv.cpp
! src/share/vm/jvmci/jvmciJavaClasses.cpp
! src/share/vm/jvmci/jvmciJavaClasses.hpp
! src/share/vm/jvmci/jvmciRuntime.cpp
! src/share/vm/jvmci/jvmciRuntime.hpp
! src/share/vm/jvmci/systemDictionary_jvmci.hpp
! src/share/vm/jvmci/vmStructs_jvmci.hpp
! src/share/vm/jvmci/vmSymbols_jvmci.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/simpleThresholdPolicy.inline.hpp
! src/share/vm/runtime/thread.cpp
! test/compiler/jvmci/SecurityRestrictionsTest.java
! test/compiler/jvmci/common/CTVMUtilities.java
! test/compiler/jvmci/common/CompilerToVMHelper.java
! test/compiler/jvmci/common/JVMCIHelpers.java
+ test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java
- test/compiler/jvmci/common/services/jdk.vm.ci.compiler.Compiler
- test/compiler/jvmci/common/services/jdk.vm.ci.compiler.CompilerFactory
+ test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompiler
+ test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompilerFactory
! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java
! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java
! test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java
! test/compiler/jvmci/compilerToVM/ConstantPoolTestCase.java
! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java
! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java
! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java
! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java
! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java
! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java
! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java
! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java
! test/compiler/jvmci/compilerToVM/GetImplementorTest.java
! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java
! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java
! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java
! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java
! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java
! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java
! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java
! test/compiler/jvmci/compilerToVM/GetSymbolTest.java
! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java
! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java
! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java
! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java
! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java
! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java
! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java
! test/compiler/jvmci/compilerToVM/LookupTypeTest.java
! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java
! test/compiler/jvmci/compilerToVM/ReprofileTest.java
! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java
! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java
! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java
! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java
- test/compiler/jvmci/events/JvmciCompleteInitializationTest.config
- test/compiler/jvmci/events/JvmciCompleteInitializationTest.java
! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java
! test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/NestedBooleanOptionValueTest.java
! test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/TestOptionValue.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/FieldUniverse.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/MethodUniverse.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/NameAndSignature.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java
! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TypeUniverse.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 6f3baccef211
Author:    shade
Date:      2015-11-05 13:33 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6f3baccef211

8141044: C1 should fold (this == null) to false
Reviewed-by: jrose, roland

! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.hpp

Changeset: 09f5dc197df8
Author:    simonis
Date:      2015-11-05 10:55 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/09f5dc197df8

8141416: "expr: syntax error" due to gcc -dumpversion excluding micro
Reviewed-by: erikj, stuefe

! make/linux/makefiles/gcc.make

Changeset: f6fe5d638924
Author:    erikj
Date:      2015-11-05 15:08 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f6fe5d638924

Merge


Changeset: c57d32ee06b3
Author:    thartmann
Date:      2015-11-05 15:29 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c57d32ee06b3

8141443: jdk/test/java/util/regex/RegExTest.java fails: No match found
Summary: Do not sign extend when converting jbyte to jchar.
Reviewed-by: shade, kvn

! src/share/vm/opto/stringopts.cpp

Changeset: f291674594da
Author:    shade
Date:      2015-11-05 16:35 +0300
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f291674594da

8140389: Remove StringCharIntrinsics flag after JDK-8138651 is fixed
Reviewed-by: kvn, zmajo

! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a20807e48002
Author:    neliasso
Date:      2015-11-06 11:34 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a20807e48002

Merge

! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/AbstractAddress.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlotValue.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/UnsignedMath.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualStackSlot.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/Compiler.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/CompilerFactory.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/StartupEventListener.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SuppressFBWarnings.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/JVMCIJarsOptionDescriptorsProvider.java
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/jvmci/jvmciCompiler.cpp
! src/share/vm/jvmci/jvmciCompilerToVM.cpp
! src/share/vm/jvmci/jvmciCompilerToVM.hpp
! src/share/vm/jvmci/jvmciEnv.cpp
! src/share/vm/jvmci/jvmciJavaClasses.hpp
! src/share/vm/jvmci/jvmciRuntime.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
- test/compiler/jvmci/common/services/jdk.vm.ci.compiler.Compiler
- test/compiler/jvmci/common/services/jdk.vm.ci.compiler.CompilerFactory
! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java
- test/compiler/jvmci/events/JvmciCompleteInitializationTest.config
- test/compiler/jvmci/events/JvmciCompleteInitializationTest.java

Changeset: 29771f4b4d47
Author:    neliasso
Date:      2015-11-06 16:42 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/29771f4b4d47

8141629: Hs-comp doesn't build with JDK-8139040
Summary: Fix benign uninitialized vars
Reviewed-by: roland

! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/opto/library_call.cpp

Changeset: 9e2ae607c0d8
Author:    amurillo
Date:      2015-11-06 11:11 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9e2ae607c0d8

Merge

- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/AbstractAddress.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlotValue.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/UnsignedMath.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualStackSlot.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/Compiler.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/CompilerFactory.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/StartupEventListener.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SuppressFBWarnings.java
- src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/JVMCIJarsOptionDescriptorsProvider.java
- test/compiler/jvmci/common/services/jdk.vm.ci.compiler.Compiler
- test/compiler/jvmci/common/services/jdk.vm.ci.compiler.CompilerFactory
- test/compiler/jvmci/events/JvmciCompleteInitializationTest.config
- test/compiler/jvmci/events/JvmciCompleteInitializationTest.java

Changeset: d8b24776484c
Author:    lana
Date:      2015-11-12 18:29 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/d8b24776484c

Merge


Changeset: afbcc2bdb3fc
Author:    lana
Date:      2015-11-19 09:36 -0800
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/afbcc2bdb3fc

Added tag jdk9-b93 for changeset d8b24776484c

! .hgtags

Changeset: e9251ccec4ec
Author:    mcimadamore
Date:      2015-11-23 11:53 +0000
URL:       http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e9251ccec4ec

merge with b93

! agent/src/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapSet.java
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/gc/cms/adaptiveFreeList.cpp
! src/share/vm/gc/cms/allocationStats.hpp
! src/share/vm/gc/cms/compactibleFreeListSpace.cpp
! src/share/vm/gc/cms/compactibleFreeListSpace.hpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc/cms/concurrentMarkSweepThread.cpp
! src/share/vm/gc/cms/concurrentMarkSweepThread.hpp
! src/share/vm/gc/cms/parCardTableModRefBS.cpp
! src/share/vm/gc/cms/parNewGeneration.cpp
! src/share/vm/gc/cms/promotionInfo.hpp
! src/share/vm/gc/cms/vmCMSOperations.cpp
! src/share/vm/gc/cms/vmCMSOperations.hpp
! src/share/vm/gc/cms/yieldingWorkgroup.cpp
! src/share/vm/gc/g1/bufferingOopClosure.cpp
! src/share/vm/gc/g1/collectionSetChooser.cpp
! src/share/vm/gc/g1/collectionSetChooser.hpp
! src/share/vm/gc/g1/concurrentG1Refine.cpp
! src/share/vm/gc/g1/concurrentG1Refine.hpp
! src/share/vm/gc/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc/g1/concurrentG1RefineThread.hpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.hpp
! src/share/vm/gc/g1/concurrentMark.inline.hpp
! src/share/vm/gc/g1/concurrentMarkThread.cpp
! src/share/vm/gc/g1/concurrentMarkThread.hpp
! src/share/vm/gc/g1/g1AllocRegion.cpp
! src/share/vm/gc/g1/g1AllocRegion.hpp
! src/share/vm/gc/g1/g1AllocRegion.inline.hpp
! src/share/vm/gc/g1/g1Allocator.cpp
! src/share/vm/gc/g1/g1Allocator.hpp
! src/share/vm/gc/g1/g1BiasedArray.cpp
! src/share/vm/gc/g1/g1BiasedArray.hpp
! src/share/vm/gc/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc/g1/g1BlockOffsetTable.hpp
! src/share/vm/gc/g1/g1BlockOffsetTable.inline.hpp
! src/share/vm/gc/g1/g1CardCounts.cpp
! src/share/vm/gc/g1/g1CardCounts.hpp
! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1ErgoVerbose.cpp
! src/share/vm/gc/g1/g1ErgoVerbose.hpp
! src/share/vm/gc/g1/g1EvacFailure.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc/g1/g1HotCardCache.cpp
! src/share/vm/gc/g1/g1HotCardCache.hpp
! src/share/vm/gc/g1/g1InCSetState.hpp
! src/share/vm/gc/g1/g1MMUTracker.cpp
! src/share/vm/gc/g1/g1MMUTracker.hpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/g1/g1OopClosures.inline.hpp
! src/share/vm/gc/g1/g1PageBasedVirtualSpace.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp
! src/share/vm/gc/g1/g1RegionToSpaceMapper.cpp
! src/share/vm/gc/g1/g1RemSet.cpp
! src/share/vm/gc/g1/g1RemSet.hpp
! src/share/vm/gc/g1/g1RootProcessor.cpp
! src/share/vm/gc/g1/g1RootProcessor.hpp
! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp
! src/share/vm/gc/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/gc/g1/g1StringDedupTable.cpp
! src/share/vm/gc/g1/g1StringDedupTable.hpp
! src/share/vm/gc/g1/g1_globals.hpp
! src/share/vm/gc/g1/heapRegion.cpp
! src/share/vm/gc/g1/heapRegion.hpp
! src/share/vm/gc/g1/heapRegion.inline.hpp
! src/share/vm/gc/g1/heapRegionManager.cpp
! src/share/vm/gc/g1/heapRegionManager.inline.hpp
! src/share/vm/gc/g1/heapRegionRemSet.cpp
! src/share/vm/gc/g1/heapRegionRemSet.hpp
! src/share/vm/gc/g1/heapRegionSet.cpp
! src/share/vm/gc/g1/heapRegionSet.inline.hpp
! src/share/vm/gc/g1/heapRegionType.hpp
! src/share/vm/gc/g1/satbQueue.cpp
! src/share/vm/gc/g1/survRateGroup.cpp
! src/share/vm/gc/g1/survRateGroup.hpp
! src/share/vm/gc/g1/vm_operations_g1.cpp
! src/share/vm/gc/g1/vm_operations_g1.hpp
! src/share/vm/gc/parallel/cardTableExtension.cpp
! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp
! src/share/vm/gc/parallel/gcTaskThread.cpp
! src/share/vm/gc/parallel/mutableNUMASpace.cpp
! src/share/vm/gc/parallel/objectStartArray.cpp
! src/share/vm/gc/parallel/objectStartArray.hpp
! src/share/vm/gc/parallel/parMarkBitMap.hpp
! src/share/vm/gc/parallel/parallelScavengeHeap.inline.hpp
! src/share/vm/gc/parallel/pcTasks.cpp
! src/share/vm/gc/parallel/psAdaptiveSizePolicy.cpp
! src/share/vm/gc/parallel/psAdaptiveSizePolicy.hpp
! src/share/vm/gc/parallel/psCompactionManager.cpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psOldGen.hpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psParallelCompact.hpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/serial/markSweep.hpp
! src/share/vm/gc/serial/tenuredGeneration.cpp
! src/share/vm/gc/serial/tenuredGeneration.hpp
! src/share/vm/gc/shared/ageTable.cpp
! src/share/vm/gc/shared/barrierSet.hpp
! src/share/vm/gc/shared/blockOffsetTable.cpp
! src/share/vm/gc/shared/cardGeneration.cpp
! src/share/vm/gc/shared/cardGeneration.hpp
! src/share/vm/gc/shared/cardTableModRefBS.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/cardTableRS.hpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/collectedHeap.hpp
! src/share/vm/gc/shared/collectedHeap.inline.hpp
! src/share/vm/gc/shared/collectorPolicy.cpp
! src/share/vm/gc/shared/collectorPolicy.hpp
! src/share/vm/gc/shared/concurrentGCThread.cpp
! src/share/vm/gc/shared/concurrentGCThread.hpp
! src/share/vm/gc/shared/gcCause.hpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp
! src/share/vm/gc/shared/gcTrace.cpp
! src/share/vm/gc/shared/gcTrace.hpp
! src/share/vm/gc/shared/gcTraceSend.cpp
! src/share/vm/gc/shared/gcTraceTime.cpp
! src/share/vm/gc/shared/gcTraceTime.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.hpp
! src/share/vm/gc/shared/genOopClosures.hpp
! src/share/vm/gc/shared/genOopClosures.inline.hpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
! src/share/vm/gc/shared/generation.cpp
! src/share/vm/gc/shared/generation.hpp
! src/share/vm/gc/shared/generationSpec.cpp
! src/share/vm/gc/shared/generationSpec.hpp
! src/share/vm/gc/shared/objectCountEventSender.cpp
! src/share/vm/gc/shared/objectCountEventSender.hpp
! src/share/vm/gc/shared/plab.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/referenceProcessor.hpp
! src/share/vm/gc/shared/space.cpp
! src/share/vm/gc/shared/space.hpp
! src/share/vm/gc/shared/taskqueue.cpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/gc/shared/workgroup.cpp
! src/share/vm/gc/shared/workgroup.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/memory/virtualspace.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/unsafe.cpp
- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh
! test/testlibrary/jdk/test/lib/ProcessTools.java
! test/testlibrary/jdk/test/lib/Utils.java