From coleen.phillimore at oracle.com  Thu Jan  2 09:25:25 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Thu, 02 Jan 2014 12:25:25 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets SIGSEGV
	in Metaspace:,:contains
Message-ID: <52C5A105.6030804@oracle.com>

Summary: Metaspace::contains cannot look at purged metaspaces while CMS 
concurrently deallocates them.

Removed 2 calls to is_metaspace_object where the object may be in a 
deallocated metaspace.  Removed walking virtual space lists for 
determining contains because the virtual space list can change 
concurrently with the walk.   CLDG::contains is slower but no slowdowns 
with testing were observed.

Tested by SQE testbase tests, jtreg tests.   Functional testing by 
parallel class loading tests and nsk/coverage/arguments/arguments008 
(ie. calls Method::is_valid_method)

open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
bug link https://bugs.openjdk.java.net/browse/JDK-8029178

Thanks,
Coleen

From serguei.spitsyn at oracle.com  Thu Jan  2 17:30:23 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 02 Jan 2014 17:30:23 -0800
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C5A105.6030804@oracle.com>
References: <52C5A105.6030804@oracle.com>
Message-ID: <52C612AF.8070203@oracle.com>

Hi Coleen,

The fix looks Ok to me.

Thanks,
Serguei

On 1/2/14 9:25 AM, Coleen Phillmore wrote:
> Summary: Metaspace::contains cannot look at purged metaspaces while 
> CMS concurrently deallocates them.
>
> Removed 2 calls to is_metaspace_object where the object may be in a 
> deallocated metaspace.  Removed walking virtual space lists for 
> determining contains because the virtual space list can change 
> concurrently with the walk.   CLDG::contains is slower but no 
> slowdowns with testing were observed.
>
> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
> parallel class loading tests and nsk/coverage/arguments/arguments008 
> (ie. calls Method::is_valid_method)
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Thu Jan  2 17:49:03 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Thu, 02 Jan 2014 20:49:03 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C612AF.8070203@oracle.com>
References: <52C5A105.6030804@oracle.com> <52C612AF.8070203@oracle.com>
Message-ID: <52C6170F.2070507@oracle.com>


Thanks, Serguei!
Coleen

On 1/2/2014 8:30 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> The fix looks Ok to me.
>
> Thanks,
> Serguei
>
> On 1/2/14 9:25 AM, Coleen Phillmore wrote:
>> Summary: Metaspace::contains cannot look at purged metaspaces while 
>> CMS concurrently deallocates them.
>>
>> Removed 2 calls to is_metaspace_object where the object may be in a 
>> deallocated metaspace.  Removed walking virtual space lists for 
>> determining contains because the virtual space list can change 
>> concurrently with the walk.   CLDG::contains is slower but no 
>> slowdowns with testing were observed.
>>
>> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
>> parallel class loading tests and nsk/coverage/arguments/arguments008 
>> (ie. calls Method::is_valid_method)
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>
>> Thanks,
>> Coleen
>


From mikael.gerdin at oracle.com  Fri Jan  3 01:31:45 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 03 Jan 2014 10:31:45 +0100
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:, :contains
In-Reply-To: <52C5A105.6030804@oracle.com>
References: <52C5A105.6030804@oracle.com>
Message-ID: <2123063.A47GYTV0Jp@mgerdin03>

Coleen,

On Thursday 02 January 2014 12.25.25 Coleen Phillmore wrote:
> Summary: Metaspace::contains cannot look at purged metaspaces while CMS
> concurrently deallocates them.
> 
> Removed 2 calls to is_metaspace_object where the object may be in a
> deallocated metaspace.  Removed walking virtual space lists for
> determining contains because the virtual space list can change
> concurrently with the walk.   CLDG::contains is slower but no slowdowns
> with testing were observed.
> 
> Tested by SQE testbase tests, jtreg tests.   Functional testing by
> parallel class loading tests and nsk/coverage/arguments/arguments008
> (ie. calls Method::is_valid_method)
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/

--- old/src/share/vm/code/dependencies.cpp	2014-01-02 
12:04:06.325014397 -0500
+++ new/src/share/vm/code/dependencies.cpp	2014-01-02 
12:04:05.877014397 -0500
@@ -655,8 +655,6 @@
   } else {
     o = _deps->oop_recorder()->metadata_at(i);
   }
-  assert(o == NULL || o->is_metaspace_object(),
-         err_msg("Should be metadata " PTR_FORMAT, o));
   return o;
 }
Why did you remove only this call to is_metaspace_object and no other?
This and none of the other callers of is_metaspace_object seem to be in any hot 
path so I agree with your assessment that this should not be a performance issue.

It seems to me that the core of the change is to not check the _unloading list in 
CLDG::contains and then change all calls to go through CLDG::contains, the CLD and 
then the SpaceManagers and Chunks, that seems like a reasonable approach.

I like that you put CLDG::contains in PRODUCT in os::print_location!

The old code incorrectly calls the static Metaspace::contains for each CLD in 
CLDG::contains but calls it like metaspace_or_null->contains(x) so it's not strange 
that it was found to be slow :)

/Mikael

> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
> 
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Fri Jan  3 04:57:40 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Fri, 03 Jan 2014 07:57:40 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <2123063.A47GYTV0Jp@mgerdin03>
References: <52C5A105.6030804@oracle.com> <2123063.A47GYTV0Jp@mgerdin03>
Message-ID: <52C6B3C4.5090907@oracle.com>


Mikael,

Thanks for reviewing the code.  See below.

On 1/3/2014 4:31 AM, Mikael Gerdin wrote:
>
> Coleen,
>
> On Thursday 02 January 2014 12.25.25 Coleen Phillmore wrote:
>
> > Summary: Metaspace::contains cannot look at purged metaspaces while CMS
>
> > concurrently deallocates them.
>
> >
>
> > Removed 2 calls to is_metaspace_object where the object may be in a
>
> > deallocated metaspace. Removed walking virtual space lists for
>
> > determining contains because the virtual space list can change
>
> > concurrently with the walk. CLDG::contains is slower but no slowdowns
>
> > with testing were observed.
>
> >
>
> > Tested by SQE testbase tests, jtreg tests. Functional testing by
>
> > parallel class loading tests and nsk/coverage/arguments/arguments008
>
> > (ie. calls Method::is_valid_method)
>
> >
>
> > open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>
> --- old/src/share/vm/code/dependencies.cpp 2014-01-02 
> 12:04:06.325014397 -0500
>
> +++ new/src/share/vm/code/dependencies.cpp	2014-01-02 12:04:05.877014397 -0500
> @@ -655,8 +655,6 @@
>     } else {
>       o = _deps->oop_recorder()->metadata_at(i);
>     }
> -  assert(o == NULL || o->is_metaspace_object(),
> -         err_msg("Should be metadata " PTR_FORMAT, o));
>     return o;
>   }
>
> Why did you remove only this call to is_metaspace_object and no other?
>
> This and none of the other callers of is_metaspace_object seem to be 
> in any hot path so I agree with your assessment that this should not 
> be a performance issue.
>

This one is called indirectly by flush_dependencies so could be called 
for unloaded metaspaces.  I hadn't removed any to start out.
>
>
> It seems to me that the core of the change is to not check the 
> _unloading list in CLDG::contains and then change all calls to go 
> through CLDG::contains, the CLD and then the SpaceManagers and Chunks, 
> that seems like a reasonable approach.
>
> I like that you put CLDG::contains in PRODUCT in os::print_location!
>

Yes, this could be improved to ask is_valid_method or 
is_valid_constant_pool or the other metadata objects and call print, but 
many metaspace objects don't have vtables, so we'd have to check directly.

> The old code incorrectly calls the static Metaspace::contains for each 
> CLD in CLDG::contains but calls it like metaspace_or_null->contains(x) 
> so it's not strange that it was found to be slow :)
>

Yes, the old code was wrong and so one of them had to go.

Thanks,
Coleen

> /Mikael
>
> > bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>
> >
>
> > Thanks,
>
> > Coleen
>


From mikael.gerdin at oracle.com  Fri Jan  3 05:34:28 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 03 Jan 2014 14:34:28 +0100
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:, :contains
In-Reply-To: <52C6B3C4.5090907@oracle.com>
References: <52C5A105.6030804@oracle.com> <2123063.A47GYTV0Jp@mgerdin03>
	<52C6B3C4.5090907@oracle.com>
Message-ID: <1976195.2cRLc1hKiI@mgerdin03>

On Friday 03 January 2014 07.57.40 Coleen Phillmore wrote:
> Mikael,
> 
> Thanks for reviewing the code.  See below.
> 
> On 1/3/2014 4:31 AM, Mikael Gerdin wrote:
> > Coleen,
> > 
> > On Thursday 02 January 2014 12.25.25 Coleen Phillmore wrote:
> > > Summary: Metaspace::contains cannot look at purged metaspaces while CMS
> > > 
> > > concurrently deallocates them.
> > > 
> > > 
> > > 
> > > Removed 2 calls to is_metaspace_object where the object may be in a
> > > 
> > > deallocated metaspace. Removed walking virtual space lists for
> > > 
> > > determining contains because the virtual space list can change
> > > 
> > > concurrently with the walk. CLDG::contains is slower but no slowdowns
> > > 
> > > with testing were observed.
> > > 
> > > 
> > > 
> > > Tested by SQE testbase tests, jtreg tests. Functional testing by
> > > 
> > > parallel class loading tests and nsk/coverage/arguments/arguments008
> > > 
> > > (ie. calls Method::is_valid_method)
> > > 
> > > 
> > > 
> > > open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
> > 
> > --- old/src/share/vm/code/dependencies.cpp 2014-01-02
> > 12:04:06.325014397 -0500
> > 
> > +++ new/src/share/vm/code/dependencies.cpp	2014-01-02 
12:04:05.877014397
> > -0500 @@ -655,8 +655,6 @@
> > 
> >     } else {
> >     
> >       o = _deps->oop_recorder()->metadata_at(i);
> >     
> >     }
> > 
> > -  assert(o == NULL || o->is_metaspace_object(),
> > -         err_msg("Should be metadata " PTR_FORMAT, o));
> > 
> >     return o;
> >   
> >   }
> > 
> > Why did you remove only this call to is_metaspace_object and no other?
> > 
> > This and none of the other callers of is_metaspace_object seem to be
> > in any hot path so I agree with your assessment that this should not
> > be a performance issue.
> 
> This one is called indirectly by flush_dependencies so could be called
> for unloaded metaspaces.  I hadn't removed any to start out.

Ok.
Ship it!

/Mikael

> 
> > It seems to me that the core of the change is to not check the
> > _unloading list in CLDG::contains and then change all calls to go
> > through CLDG::contains, the CLD and then the SpaceManagers and Chunks,
> > that seems like a reasonable approach.
> > 
> > I like that you put CLDG::contains in PRODUCT in os::print_location!
> 
> Yes, this could be improved to ask is_valid_method or
> is_valid_constant_pool or the other metadata objects and call print, but
> many metaspace objects don't have vtables, so we'd have to check directly.
> 
> > The old code incorrectly calls the static Metaspace::contains for each
> > CLD in CLDG::contains but calls it like metaspace_or_null->contains(x)
> > so it's not strange that it was found to be slow :)
> 
> Yes, the old code was wrong and so one of them had to go.
> 
> Thanks,
> Coleen
> 
> > /Mikael
> > 
> > > bug link https://bugs.openjdk.java.net/browse/JDK-8029178
> > > 
> > > 
> > > 
> > > Thanks,
> > > 
> > > Coleen


From jon.masamitsu at oracle.com  Fri Jan  3 10:09:38 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 03 Jan 2014 10:09:38 -0800
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C5A105.6030804@oracle.com>
References: <52C5A105.6030804@oracle.com>
Message-ID: <52C6FCE2.8000906@oracle.com>

Coleen,

http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html

146   bool contains(const void* ptr) { return bottom() < ptr && ptr <= _top; }

I think bottom() points to the first chunk.  Also _top points to the start
of the unallocated space (next place where a chunk will be allocated).
So I would think this should be

bool contains(const void* ptr) { return bottom() <=ptr && ptr < _top; }

  

http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html

Don't you need some locking to protect the "chunks_in_use()" lists?

2382 bool SpaceManager::contains(const void *ptr) {
2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = next_chunk_index(i))
2384   {
2385     Metachunk* curr = chunks_in_use(i);
2386     while (curr != NULL) {
2387       if (curr->contains(ptr)) return true;
2388       curr = curr->next();
2389     }
2390   }
2391   return false;
2392 }
2393

Jon


On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
> Summary: Metaspace::contains cannot look at purged metaspaces while 
> CMS concurrently deallocates them.
>
> Removed 2 calls to is_metaspace_object where the object may be in a 
> deallocated metaspace.  Removed walking virtual space lists for 
> determining contains because the virtual space list can change 
> concurrently with the walk.   CLDG::contains is slower but no 
> slowdowns with testing were observed.
>
> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
> parallel class loading tests and nsk/coverage/arguments/arguments008 
> (ie. calls Method::is_valid_method)
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Fri Jan  3 11:00:13 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Fri, 03 Jan 2014 14:00:13 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C6FCE2.8000906@oracle.com>
References: <52C5A105.6030804@oracle.com> <52C6FCE2.8000906@oracle.com>
Message-ID: <52C708BD.9090401@oracle.com>


Jon,  Thanks for reviewing this.

On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
> Coleen,
>
> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>
>
> 146   bool contains(const void* ptr) { return bottom() < ptr && ptr <= 
> _top; }
>
> I think bottom() points to the first chunk.  Also _top points to the 
> start
> of the unallocated space (next place where a chunk will be allocated).
> So I would think this should be
>
> bool contains(const void* ptr) { return bottom() <=ptr && ptr < _top; }
>
>

Yes, I agree.
>
> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>
>
> Don't you need some locking to protect the "chunks_in_use()" lists?
>
> 2382 bool SpaceManager::contains(const void *ptr) {
> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
> next_chunk_index(i))
> 2384   {
> 2385     Metachunk* curr = chunks_in_use(i);
> 2386     while (curr != NULL) {
> 2387       if (curr->contains(ptr)) return true;
> 2388       curr = curr->next();
> 2389     }
> 2390   }
> 2391   return false;
> 2392 }
> 2393

If new chunks are added while this is iterating over them, they are 
added to the front of the list.  This is ok because we would only call 
this for metadata that is already allocated in one of the chunks.   I 
don't want to add a lock but I do need some memory ordering 
instructions.   I'll move the one that I had on virtual space lists to 
where we add the chunks.

The Metaspace/SpaceManager destructors can only be called for the 
_unloading list, which is created at a safepoint and we don't walk those 
lists in CLDG::contains.

Thank you for pointing these out.   I'll retest and send out another webrev.

Coleen
>
> Jon
>
>
> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>> Summary: Metaspace::contains cannot look at purged metaspaces while 
>> CMS concurrently deallocates them.
>>
>> Removed 2 calls to is_metaspace_object where the object may be in a 
>> deallocated metaspace.  Removed walking virtual space lists for 
>> determining contains because the virtual space list can change 
>> concurrently with the walk.   CLDG::contains is slower but no 
>> slowdowns with testing were observed.
>>
>> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
>> parallel class loading tests and nsk/coverage/arguments/arguments008 
>> (ie. calls Method::is_valid_method)
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>
>> Thanks,
>> Coleen
>


From jon.masamitsu at oracle.com  Fri Jan  3 11:38:05 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 03 Jan 2014 11:38:05 -0800
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C708BD.9090401@oracle.com>
References: <52C5A105.6030804@oracle.com> <52C6FCE2.8000906@oracle.com>
	<52C708BD.9090401@oracle.com>
Message-ID: <52C7119D.9020601@oracle.com>


On 1/3/2014 11:00 AM, Coleen Phillmore wrote:
>
> Jon,  Thanks for reviewing this.
>
> On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
>> Coleen,
>>
>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>>
>>
>> 146   bool contains(const void* ptr) { return bottom() < ptr && ptr 
>> <= _top; }
>>
>> I think bottom() points to the first chunk.  Also _top points to the 
>> start
>> of the unallocated space (next place where a chunk will be allocated).
>> So I would think this should be
>>
>> bool contains(const void* ptr) { return bottom() <=ptr && ptr < _top; }
>>
>>
>
> Yes, I agree.
>>
>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>>
>>
>> Don't you need some locking to protect the "chunks_in_use()" lists?
>>
>> 2382 bool SpaceManager::contains(const void *ptr) {
>> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
>> next_chunk_index(i))
>> 2384   {
>> 2385     Metachunk* curr = chunks_in_use(i);
>> 2386     while (curr != NULL) {
>> 2387       if (curr->contains(ptr)) return true;
>> 2388       curr = curr->next();
>> 2389     }
>> 2390   }
>> 2391   return false;
>> 2392 }
>> 2393
>
> If new chunks are added while this is iterating over them, they are 
> added to the front of the list.  This is ok because we would only call 
> this for metadata that is already allocated in one of the chunks.   I 
> don't want to add a lock but I do need some memory ordering 
> instructions.   I'll move the one that I had on virtual space lists to 
> where we add the chunks.

Ok.  Do you think it is worth code in set_chunks_in_use() that checks
that the list head is set after the new chunk has been added?

Something like

set_chunks_in_use(new_chunk)
if (chunks_in_use() != NULL)
     assert(new_chunk->next == chunks_in_use(), "Always add new chunk to 
list first");
}

Just a thought.

Jon



>
> The Metaspace/SpaceManager destructors can only be called for the 
> _unloading list, which is created at a safepoint and we don't walk 
> those lists in CLDG::contains.
>
> Thank you for pointing these out.   I'll retest and send out another 
> webrev.
>
> Coleen
>>
>> Jon
>>
>>
>> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>>> Summary: Metaspace::contains cannot look at purged metaspaces while 
>>> CMS concurrently deallocates them.
>>>
>>> Removed 2 calls to is_metaspace_object where the object may be in a 
>>> deallocated metaspace.  Removed walking virtual space lists for 
>>> determining contains because the virtual space list can change 
>>> concurrently with the walk.   CLDG::contains is slower but no 
>>> slowdowns with testing were observed.
>>>
>>> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
>>> parallel class loading tests and nsk/coverage/arguments/arguments008 
>>> (ie. calls Method::is_valid_method)
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>>
>>> Thanks,
>>> Coleen
>>
>


From coleen.phillimore at oracle.com  Fri Jan  3 12:00:35 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Fri, 03 Jan 2014 15:00:35 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C7119D.9020601@oracle.com>
References: <52C5A105.6030804@oracle.com> <52C6FCE2.8000906@oracle.com>
	<52C708BD.9090401@oracle.com> <52C7119D.9020601@oracle.com>
Message-ID: <52C716E3.1000105@oracle.com>


On 1/3/2014 2:38 PM, Jon Masamitsu wrote:
>
> On 1/3/2014 11:00 AM, Coleen Phillmore wrote:
>>
>> Jon,  Thanks for reviewing this.
>>
>> On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
>>> Coleen,
>>>
>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>>>
>>>
>>> 146   bool contains(const void* ptr) { return bottom() < ptr && ptr 
>>> <= _top; }
>>>
>>> I think bottom() points to the first chunk.  Also _top points to the 
>>> start
>>> of the unallocated space (next place where a chunk will be allocated).
>>> So I would think this should be
>>>
>>> bool contains(const void* ptr) { return bottom() <=ptr && ptr < _top; }
>>>
>>>
>>
>> Yes, I agree.
>>>
>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>>>
>>>
>>> Don't you need some locking to protect the "chunks_in_use()" lists?
>>>
>>> 2382 bool SpaceManager::contains(const void *ptr) {
>>> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
>>> next_chunk_index(i))
>>> 2384   {
>>> 2385     Metachunk* curr = chunks_in_use(i);
>>> 2386     while (curr != NULL) {
>>> 2387       if (curr->contains(ptr)) return true;
>>> 2388       curr = curr->next();
>>> 2389     }
>>> 2390   }
>>> 2391   return false;
>>> 2392 }
>>> 2393
>>
>> If new chunks are added while this is iterating over them, they are 
>> added to the front of the list.  This is ok because we would only 
>> call this for metadata that is already allocated in one of the 
>> chunks.   I don't want to add a lock but I do need some memory 
>> ordering instructions.   I'll move the one that I had on virtual 
>> space lists to where we add the chunks.
>
> Ok.  Do you think it is worth code in set_chunks_in_use() that checks
> that the list head is set after the new chunk has been added?
>
> Something like
>
> set_chunks_in_use(new_chunk)
> if (chunks_in_use() != NULL)
>     assert(new_chunk->next == chunks_in_use(), "Always add new chunk 
> to list first");
> }

I think the OrderAccess::storestore() should accomplish this. 
chunks_in_use() shouldn't be null after this though except for at 
deletion time.   So this code seems overly paranoid about the C++ 
compiler not doing the stores.  Actually the C++ compiler could keep all 
of this in a register and we'd never see things in the right order.

Here's a new version with the OrderAccess::storestore();   I reran the 
parallel class loading tests on this.

http://cr.openjdk.java.net/~coleenp/8029178_2/ 
<http://cr.openjdk.java.net/%7Ecoleenp/8029178_2/>

Thanks,
Coleen
>
> Just a thought.
>
> Jon
>
>
>
>>
>> The Metaspace/SpaceManager destructors can only be called for the 
>> _unloading list, which is created at a safepoint and we don't walk 
>> those lists in CLDG::contains.
>>
>> Thank you for pointing these out.   I'll retest and send out another 
>> webrev.
>>
>> Coleen
>>>
>>> Jon
>>>
>>>
>>> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>>>> Summary: Metaspace::contains cannot look at purged metaspaces while 
>>>> CMS concurrently deallocates them.
>>>>
>>>> Removed 2 calls to is_metaspace_object where the object may be in a 
>>>> deallocated metaspace.  Removed walking virtual space lists for 
>>>> determining contains because the virtual space list can change 
>>>> concurrently with the walk. CLDG::contains is slower but no 
>>>> slowdowns with testing were observed.
>>>>
>>>> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
>>>> parallel class loading tests and 
>>>> nsk/coverage/arguments/arguments008 (ie. calls 
>>>> Method::is_valid_method)
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>


From john.coomes at oracle.com  Fri Jan  3 12:32:12 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:32:12 +0000
Subject: hg: hsx/hotspot-main: Added tag jdk8-b122 for changeset 347009c58816
Message-ID: <20140103203212.ABAE26236E@hg.openjdk.java.net>

Changeset: ff1478785e43
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/ff1478785e43

Added tag jdk8-b122 for changeset 347009c58816

! .hgtags


From john.coomes at oracle.com  Fri Jan  3 12:32:46 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:32:46 +0000
Subject: hg: hsx/hotspot-main/jaxp: 7 new changesets
Message-ID: <20140103203311.6E8DE62371@hg.openjdk.java.net>

Changeset: 3e5bf0372a93
Author:    joehw
Date:      2013-12-12 11:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/3e5bf0372a93

8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
Reviewed-by: alanb, dfuchs, lancea

! src/javax/xml/stream/XMLOutputFactory.java

Changeset: 9c7e3a68dc77
Author:    lana
Date:      2013-12-12 19:13 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/9c7e3a68dc77

Merge


Changeset: fad4b4d28599
Author:    lana
Date:      2013-12-23 14:43 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/fad4b4d28599

Merge


Changeset: 1bedbbce236a
Author:    joehw
Date:      2013-12-20 09:51 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/1bedbbce236a

8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars
Reviewed-by: dfuchs, lancea, ulfzibis

! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java

Changeset: 9a3986b21be4
Author:    joehw
Date:      2013-12-23 11:26 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/9a3986b21be4

8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
Reviewed-by: lancea, mchung

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
! src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java
! src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java
! src/com/sun/org/apache/xerces/internal/impl/Constants.java
! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java
! src/com/sun/xml/internal/stream/Entity.java
! src/com/sun/xml/internal/stream/StaxXMLInputSource.java
! src/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/com/sun/xml/internal/stream/writers/WriterUtility.java
! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java
! src/javax/xml/XMLConstants.java
! src/javax/xml/parsers/SAXParser.java
! src/javax/xml/validation/Validator.java
! src/javax/xml/xpath/XPathException.java
! src/javax/xml/xpath/XPathFactory.java
! src/org/xml/sax/helpers/NewInstance.java
! src/org/xml/sax/helpers/ParserAdapter.java
! src/org/xml/sax/helpers/ParserFactory.java
! src/org/xml/sax/helpers/SecuritySupport.java
! src/org/xml/sax/helpers/XMLReaderFactory.java

Changeset: 93bf25903af0
Author:    lana
Date:      2013-12-25 10:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/93bf25903af0

Merge


Changeset: 4e35b5b6d2e5
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4e35b5b6d2e5

Added tag jdk8-b122 for changeset 93bf25903af0

! .hgtags


From john.coomes at oracle.com  Fri Jan  3 12:32:26 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:32:26 +0000
Subject: hg: hsx/hotspot-main/corba: 5 new changesets
Message-ID: <20140103203232.2BE5662370@hg.openjdk.java.net>

Changeset: eb5d3f8ca0ca
Author:    mfang
Date:      2013-12-17 22:03 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/eb5d3f8ca0ca

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp

Changeset: 2a8fa4da6ad3
Author:    lana
Date:      2013-12-23 14:43 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2a8fa4da6ad3

Merge


Changeset: 5ca1b4c282b8
Author:    ssides
Date:      2013-12-23 18:42 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5ca1b4c282b8

8029231: Update copyright years for files in corba repository for 2013
Reviewed-by: mchung, coffeys

! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java
! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java
! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java
! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java
! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java
! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties
! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java
! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java
! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp
! src/share/classes/javax/rmi/CORBA/Stub.java
! src/share/classes/javax/rmi/CORBA/Util.java
! src/share/classes/javax/rmi/PortableRemoteObject.java
! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java

Changeset: 0cd687347540
Author:    lana
Date:      2013-12-25 10:30 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0cd687347540

Merge


Changeset: 1ecd4619f60c
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/1ecd4619f60c

Added tag jdk8-b122 for changeset 0cd687347540

! .hgtags


From john.coomes at oracle.com  Fri Jan  3 12:33:20 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:33:20 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b122 for changeset
	bc622ba563f9
Message-ID: <20140103203328.DB54A62372@hg.openjdk.java.net>

Changeset: 91f5c542ccad
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/91f5c542ccad

Added tag jdk8-b122 for changeset bc622ba563f9

! .hgtags


From john.coomes at oracle.com  Fri Jan  3 12:36:32 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:36:32 +0000
Subject: hg: hsx/hotspot-main/jdk: 41 new changesets
Message-ID: <20140103204603.BE99C62373@hg.openjdk.java.net>

Changeset: c8c4aef922ff
Author:    vadim
Date:      2013-12-13 11:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8c4aef922ff

8029628: Many graphic artifacts
Reviewed-by: prr, bae

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 6ecbfe5e211b
Author:    lana
Date:      2013-12-19 10:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ecbfe5e211b

Merge


Changeset: 9e0e8eed676a
Author:    pchelko
Date:      2013-12-06 17:47 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9e0e8eed676a

8029565: java.awt.dnd.InvalidDnDOperationException: data translation failed on file drop
Reviewed-by: anthony, serb

! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/SourceFileListFrame.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/TargetFileListFrame.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.html
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListTransferable.java

Changeset: 152cf399f16f
Author:    serb
Date:      2013-12-11 22:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/152cf399f16f

8029045: Regression - Unsatisfied Link Error when the Java Access Bridge is started
Summary: Rename native function name; fix make to rebuild jni header file
Reviewed-by: erikj, tbell
Contributed-by: peter.brunet at oracle.com

! make/CompileJavaClasses.gmk

Changeset: 06c655658b89
Author:    serb
Date:      2013-12-12 16:30 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/06c655658b89

8001472: api/java_awt/Window/indexTGF_* tests fail because expected colors aren't equal
Reviewed-by: anthony, azvegint

! src/solaris/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java

Changeset: 78d395c7c479
Author:    lana
Date:      2013-12-12 20:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78d395c7c479

Merge

- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED
- test/com/sun/jmx/snmp/NoInfoLeakTest.java
- test/com/sun/tools/attach/AgentSetup.sh
- test/com/sun/tools/attach/ApplicationSetup.sh
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
- test/com/sun/tools/attach/PermissionTests.sh
- test/com/sun/tools/attach/ProviderTests.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh

Changeset: 20d504a20a87
Author:    azvegint
Date:      2013-12-13 14:29 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/20d504a20a87

8029923: Many Swing tests and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load native GTK libraries"
Reviewed-by: anthony, serb

! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h

Changeset: c8ec5c070592
Author:    azvegint
Date:      2013-12-18 11:09 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8ec5c070592

8029263: user's default browser can not launch after we click the button, and there is an IOException shown in the log text (java.io.IOException)
Reviewed-by: anthony, serb

! src/solaris/classes/sun/awt/X11/XDesktopPeer.java
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c
! test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java

Changeset: 4ee27281d27d
Author:    lana
Date:      2013-12-19 10:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4ee27281d27d

Merge


Changeset: f8da1f34c65c
Author:    darcy
Date:      2013-12-06 11:28 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8da1f34c65c

8023471: Add compatibility note to AnnotatedElement
Reviewed-by: smarks, jfranck, abuckley

! src/share/classes/java/lang/annotation/Annotation.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java

Changeset: d6c4ae56c079
Author:    juh
Date:      2013-12-06 11:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6c4ae56c079

8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward()
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java

Changeset: 9e579a2329c0
Author:    michaelm
Date:      2013-12-09 13:05 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9e579a2329c0

8029354: URLPermission.<init> throws llegalArgumentException: Invalid characters in hostname
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URLPermission.java
+ test/java/net/URLPermission/OpenURL.java
! test/java/net/URLPermission/URLPermissionTest.java

Changeset: 23a7524d930c
Author:    mfang
Date:      2013-12-09 15:01 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23a7524d930c

8025974: l10n for policytool
Reviewed-by: naoto, leifs, yhuang

! src/share/classes/sun/security/tools/policytool/Resources_de.java
! src/share/classes/sun/security/tools/policytool/Resources_es.java
! src/share/classes/sun/security/tools/policytool/Resources_fr.java
! src/share/classes/sun/security/tools/policytool/Resources_it.java
! src/share/classes/sun/security/tools/policytool/Resources_ja.java
! src/share/classes/sun/security/tools/policytool/Resources_ko.java
! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/policytool/Resources_sv.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java

Changeset: fe3383582427
Author:    rriggs
Date:      2013-12-11 16:52 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fe3383582427

8029551: Add value-type notice to java.time classes
Summary: Add warning about identity of value types and reference to ValueBased.html
Reviewed-by: briangoetz, smarks, scolebourne

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java

Changeset: 1298e476729c
Author:    michaelm
Date:      2013-12-11 15:26 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1298e476729c

8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method
Reviewed-by: mduigou
Contributed-by: michael.mcmahon at oracle.com

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java

Changeset: 1970e3c3d202
Author:    michaelm
Date:      2013-12-11 15:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1970e3c3d202

8029696: Broken doc links to package-summary.html#NonInterference in java.util.stream
Reviewed-by: mduigou

! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/package-info.java

Changeset: 01b11184bcf9
Author:    mfang
Date:      2013-12-11 21:22 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01b11184bcf9

8026115: [zh_CN] inproper translation in output of jarsigner command
Reviewed-by: naoto, yhuang

! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java

Changeset: 23b89bd740e9
Author:    lana
Date:      2013-12-12 19:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23b89bd740e9

Merge


Changeset: a7ed72627c3f
Author:    mduigou
Date:      2013-12-13 13:34 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7ed72627c3f

8029055: Map.merge implementations should refuse null value param
Reviewed-by: briangoetz, dl

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! test/java/util/Map/Defaults.java

Changeset: 26028cb56c68
Author:    mduigou
Date:      2013-12-13 13:35 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/26028cb56c68

8030016: HashMap.computeIfAbsent generates spurious access event
Reviewed-by: psandoz, bchristi

! src/share/classes/java/util/HashMap.java
+ test/java/util/LinkedHashMap/ComputeIfAbsentAccessOrder.java
! test/java/util/Map/Defaults.java

Changeset: 6c343d3d2721
Author:    smarks
Date:      2013-12-13 18:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c343d3d2721

8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons
Reviewed-by: mchung, dmocek

! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/resources/rmic.properties

Changeset: 8e133b86b9f8
Author:    mduigou
Date:      2013-12-17 09:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e133b86b9f8

8029795: LinkedHashMap.getOrDefault() doesn't update access order.
Reviewed-by: psandoz

! src/share/classes/java/util/LinkedHashMap.java
! test/java/util/LinkedHashMap/Basic.java

Changeset: 4fa27233a3e9
Author:    mfang
Date:      2013-12-17 14:13 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fa27233a3e9

7090826: Newly added codes need to be localized into pt_BR in LocaleNames
Reviewed-by: okutsu

! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: 68c31754f925
Author:    vinnie
Date:      2013-12-17 23:03 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/68c31754f925

8029788: Certificate validation - java.lang.ClassCastException
Reviewed-by: xuelei, mullan, weijun

! src/share/classes/sun/security/provider/certpath/OCSPResponse.java

Changeset: 9211877b25ba
Author:    mfang
Date:      2013-12-17 23:33 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9211877b25ba

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java
! src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
! src/share/classes/sun/security/tools/keytool/Resources_de.java
! src/share/classes/sun/security/tools/keytool/Resources_es.java
! src/share/classes/sun/security/tools/keytool/Resources_fr.java
! src/share/classes/sun/security/tools/keytool/Resources_it.java
! src/share/classes/sun/security/tools/keytool/Resources_ja.java
! src/share/classes/sun/security/tools/keytool/Resources_ko.java
! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/keytool/Resources_sv.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties

Changeset: 8d35f0985dd7
Author:    xuelei
Date:      2013-12-18 16:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d35f0985dd7

7093640: Enable client-side TLS 1.2 by default
Reviewed-by: weijun, mullan, wetmore

! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: e2bdddb8bedf
Author:    dl
Date:      2013-12-19 10:31 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2bdddb8bedf

8026155: Enhance ForkJoin pool
Reviewed-by: chegar, alanb, ahgross

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java

Changeset: c841815be720
Author:    chegar
Date:      2013-12-19 10:38 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c841815be720

Merge


Changeset: a2339db970e0
Author:    lana
Date:      2013-12-19 10:26 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a2339db970e0

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 2f31ddf65e74
Author:    lana
Date:      2013-12-23 14:45 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f31ddf65e74

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 75142ce752da
Author:    malenkov
Date:      2013-12-23 16:24 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75142ce752da

8030118: Document listeners fired outside document lock
Reviewed-by: art, serb

! src/share/classes/javax/swing/text/AbstractDocument.java
- test/javax/swing/text/AbstractDocument/7146146/bug7146146.java
+ test/javax/swing/text/AbstractDocument/8030118/Test8030118.java

Changeset: 8b5985f1a0b5
Author:    lana
Date:      2013-12-25 11:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b5985f1a0b5

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 73473e9dfc46
Author:    joehw
Date:      2013-12-20 09:56 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/73473e9dfc46

8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars
Reviewed-by: dfuchs, lancea, ulfzibis

+ test/javax/xml/jaxp/parsers/8029955/EntityScannerTest.java

Changeset: 7186275e6ef1
Author:    rriggs
Date:      2013-12-20 13:06 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7186275e6ef1

8030002: Enhance deserialization using readObject
Reviewed-by: sherman, chegar, scolebourne

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/AbstractChronology.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoPeriodImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! test/java/time/tck/java/time/AbstractTCKTest.java
! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java
! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java
! test/java/time/tck/java/time/serial/TCKDurationSerialization.java
! test/java/time/tck/java/time/serial/TCKInstantSerialization.java
! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java
! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java
! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java
! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java
! test/java/time/tck/java/time/serial/TCKYearSerialization.java
! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java
! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java
! test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java
! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java
! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java
! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java
! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java

Changeset: 39a02b18b386
Author:    rriggs
Date:      2013-12-20 13:06 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39a02b18b386

8029909: Clarify equals/hashcode behavior for java.time types
Summary: Document the behavior of equals and hashcode in java.time.chrono date types
Reviewed-by: sherman, scolebourne

! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java

Changeset: aef6c726810e
Author:    mullan
Date:      2013-12-23 14:03 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aef6c726810e

8030813: Signed applet fails to load when CRLs are stored in an LDAP directory
Summary: Skip JNDI application resource lookup to avoid recursive JAR validation
Reviewed-by: vinnie, herrick

! src/share/classes/com/sun/naming/internal/ResourceManager.java
! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java

Changeset: f3c714eeef6c
Author:    mullan
Date:      2013-12-23 14:05 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3c714eeef6c

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 71ce5e56ca60
Author:    lana
Date:      2013-12-25 10:34 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71ce5e56ca60

Merge


Changeset: 1a3de3cdc684
Author:    lana
Date:      2013-12-26 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a3de3cdc684

8029235: Update copyright year to match last edit in jdk8 jdk repository for 2013
Summary: updated files with 2011, 2012 and 2013 years according to the file's last updated date
Reviewed-by: tbell, lancea, chegar

! make/BuildJdk.gmk
! make/Bundles.gmk
! make/CompileJavaClasses.gmk
! make/CompileLaunchers.gmk
! make/CopyIntoClasses.gmk
! make/CopySamples.gmk
! make/GenerateData.gmk
! make/Makefile
! make/data/characterdata/CharacterData00.java.template
! make/data/characterdata/CharacterData01.java.template
! make/data/characterdata/CharacterData02.java.template
! make/data/characterdata/CharacterData0E.java.template
! make/data/characterdata/CharacterDataLatin1.java.template
! make/data/characterdata/CharacterDataPrivateUse.java.template
! make/data/characterdata/CharacterDataUndefined.java.template
! make/data/charsetmapping/DoubleByte-X.java.template
! make/data/charsetmapping/SingleByte-X.java.template
! make/data/dtdbuilder/html32.dtd
! make/data/jdwp/jdwp.spec
! make/data/swingbeaninfo/SwingBeanInfo.template
! make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java
! make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java
! make/data/tzdata/gmt
! make/data/tzdata/jdk11_backward
! make/gendata/GendataFontConfig.gmk
! make/gendata/GendataHtml32dtd.gmk
! make/gensrc/GensrcBuffer.gmk
! make/gensrc/GensrcCLDR.gmk
! make/gensrc/GensrcCharacterData.gmk
! make/gensrc/GensrcCharsetCoder.gmk
! make/gensrc/GensrcCharsetMapping.gmk
! make/gensrc/GensrcExceptions.gmk
! make/gensrc/GensrcJDWP.gmk
! make/gensrc/GensrcJObjC.gmk
! make/gensrc/GensrcLocaleDataMetaInfo.gmk
! make/gensrc/GensrcMisc.gmk
! make/gensrc/GensrcProperties.gmk
! make/gensrc/GensrcSwing.gmk
! make/gensrc/GensrcX11Wrappers.gmk
! make/mapfiles/launchers/mapfile-sparc
! make/mapfiles/launchers/mapfile-sparcv9
! make/mapfiles/launchers/mapfile-x86
! make/mapfiles/launchers/mapfile-x86_64
! make/mapfiles/libattach/mapfile-linux
! make/mapfiles/libattach/mapfile-solaris
! make/mapfiles/libawt/mapfile-mawt-vers
! make/mapfiles/libawt/mapfile-vers
! make/mapfiles/libawt/mapfile-vers-linux
! make/mapfiles/libawt_headless/mapfile-vers
! make/mapfiles/libawt_xawt/mapfile-vers
! make/mapfiles/libdcpr/mapfile-vers
! make/mapfiles/libdt_socket/mapfile-vers
! make/mapfiles/libfontmanager/mapfile-vers
! make/mapfiles/libfontmanager/mapfile-vers.openjdk
! make/mapfiles/libhprof/mapfile-vers
! make/mapfiles/libinstrument/mapfile-vers
! make/mapfiles/libj2gss/mapfile-vers
! make/mapfiles/libj2pcsc/mapfile-vers
! make/mapfiles/libj2ucrypto/mapfile-vers
! make/mapfiles/libjaas/mapfile-vers
! make/mapfiles/libjava_crw_demo/mapfile-vers
! make/mapfiles/libjawt/mapfile-vers
! make/mapfiles/libjdga/mapfile-vers
! make/mapfiles/libjdwp/mapfile-vers
! make/mapfiles/libjli/mapfile-vers
! make/mapfiles/libjpeg/mapfile-vers
! make/mapfiles/libjpeg/mapfile-vers-closed
! make/mapfiles/libjsdt/mapfile-vers
! make/mapfiles/libjsound/mapfile-vers
! make/mapfiles/libjsoundalsa/mapfile-vers
! make/mapfiles/libkcms/mapfile-vers
! make/mapfiles/liblcms/mapfile-vers
! make/mapfiles/libmlib_image/mapfile-vers
! make/mapfiles/libnet/mapfile-vers
! make/mapfiles/libnio/mapfile-linux
! make/mapfiles/libnio/mapfile-macosx
! make/mapfiles/libnio/mapfile-solaris
! make/mapfiles/libnpt/mapfile-vers
! make/mapfiles/libsctp/mapfile-vers
! make/mapfiles/libsplashscreen/mapfile-vers
! make/mapfiles/libsunec/mapfile-vers
! make/mapfiles/libt2k/mapfile-vers
! make/mapfiles/libunpack/mapfile-vers
! make/mapfiles/libunpack/mapfile-vers-unpack200
! make/mapfiles/libverify/mapfile-vers
! make/mapfiles/libzip/mapfile-vers
! make/netbeans/common/architectures/arch-x86_64.properties
! make/netbeans/common/architectures/name-Macosx.properties
! make/netbeans/common/closed-share-sources.ent
! make/netbeans/common/demo-view.ent
! make/netbeans/common/make.xml
! make/netbeans/common/properties.ent
! make/netbeans/common/share-sources.ent
! make/netbeans/common/shared.xml
! make/netbeans/common/unix-sources.ent
! make/netbeans/common/windows-sources.ent
! make/netbeans/j2se/build.xml
! make/netbeans/jmx/build.properties
! make/non-build-utils/reorder/Makefile
! make/non-build-utils/reorder/tests/Exit.java
! make/non-build-utils/reorder/tests/Hello.java
! make/non-build-utils/reorder/tests/IntToString.java
! make/non-build-utils/reorder/tests/JHello.java
! make/non-build-utils/reorder/tests/LoadFrame.java
! make/non-build-utils/reorder/tests/LoadJFrame.java
! make/non-build-utils/reorder/tests/LoadToolkit.java
! make/non-build-utils/reorder/tests/Null.java
! make/non-build-utils/reorder/tests/Sleep.java
! make/non-build-utils/reorder/tools/Combine.java
! make/non-build-utils/reorder/tools/MaxTime.java
! make/non-build-utils/reorder/tools/mcount.c
! make/non-build-utils/reorder/tools/remove_mcount.c
! make/non-build-utils/sharing/tests/GHello.java
! make/non-build-utils/sharing/tests/Hello.java
! make/non-build-utils/sharing/tests/JHello.java
! make/non-build-utils/src/build/tools/commentchecker/CommentChecker.java
! make/non-build-utils/src/build/tools/dirdiff/DirDiff.java
! make/src/classes/build/tools/addjsum/AddJsum.java
! make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java
! make/src/classes/build/tools/charsetmapping/DBCS.java
! make/src/classes/build/tools/charsetmapping/EUC_TW.java
! make/src/classes/build/tools/charsetmapping/HKSCS.java
! make/src/classes/build/tools/charsetmapping/JIS0213.java
! make/src/classes/build/tools/charsetmapping/Main.java
! make/src/classes/build/tools/charsetmapping/SBCS.java
! make/src/classes/build/tools/charsetmapping/Utils.java
! make/src/classes/build/tools/classfile/RemoveMethods.java
! make/src/classes/build/tools/cldrconverter/BundleGenerator.java
! make/src/classes/build/tools/cldrconverter/Container.java
! make/src/classes/build/tools/cldrconverter/CopyrightHeaders.java
! make/src/classes/build/tools/cldrconverter/Entry.java
! make/src/classes/build/tools/cldrconverter/IgnoredContainer.java
! make/src/classes/build/tools/cldrconverter/KeyContainer.java
! make/src/classes/build/tools/cldrconverter/MetaZonesParseHandler.java
! make/src/classes/build/tools/cldrconverter/NumberingSystemsParseHandler.java
! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
! make/src/classes/build/tools/cldrconverter/StringArrayElement.java
! make/src/classes/build/tools/cldrconverter/StringArrayEntry.java
! make/src/classes/build/tools/cldrconverter/StringEntry.java
! make/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java
! make/src/classes/build/tools/compilefontconfig/CompileFontConfig.java
! make/src/classes/build/tools/compileproperties/CompileProperties.java
! make/src/classes/build/tools/dtdbuilder/DTDBuilder.java
! make/src/classes/build/tools/dtdbuilder/DTDInputStream.java
! make/src/classes/build/tools/dtdbuilder/DTDParser.java
! make/src/classes/build/tools/dtdbuilder/PublicMapping.java
! make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
! make/src/classes/build/tools/generatebreakiteratordata/CharSet.java
! make/src/classes/build/tools/generatebreakiteratordata/CharacterCategory.java
! make/src/classes/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
! make/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
! make/src/classes/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
! make/src/classes/build/tools/generatecharacter/GenerateCharacter.java
! make/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java
! make/src/classes/build/tools/generatecharacter/PropList.java
! make/src/classes/build/tools/generatecharacter/SpecialCaseMap.java
! make/src/classes/build/tools/generatecharacter/UnicodeSpec.java
! make/src/classes/build/tools/generatecharacter/Utility.java
! make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java
! make/src/classes/build/tools/generatenimbus/AbstractGradient.java
! make/src/classes/build/tools/generatenimbus/Border.java
! make/src/classes/build/tools/generatenimbus/Canvas.java
! make/src/classes/build/tools/generatenimbus/ComponentColor.java
! make/src/classes/build/tools/generatenimbus/Dimension.java
! make/src/classes/build/tools/generatenimbus/Ellipse.java
! make/src/classes/build/tools/generatenimbus/Generator.java
! make/src/classes/build/tools/generatenimbus/Gradient.java
! make/src/classes/build/tools/generatenimbus/GradientStop.java
! make/src/classes/build/tools/generatenimbus/Insets.java
! make/src/classes/build/tools/generatenimbus/Layer.java
! make/src/classes/build/tools/generatenimbus/Matte.java
! make/src/classes/build/tools/generatenimbus/ObjectFactory.java
! make/src/classes/build/tools/generatenimbus/Paint.java
! make/src/classes/build/tools/generatenimbus/PainterGenerator.java
! make/src/classes/build/tools/generatenimbus/Path.java
! make/src/classes/build/tools/generatenimbus/Point.java
! make/src/classes/build/tools/generatenimbus/RadialGradient.java
! make/src/classes/build/tools/generatenimbus/Rectangle.java
! make/src/classes/build/tools/generatenimbus/Shape.java
! make/src/classes/build/tools/generatenimbus/SynthModel.java
! make/src/classes/build/tools/generatenimbus/Typeface.java
! make/src/classes/build/tools/generatenimbus/UIColor.java
! make/src/classes/build/tools/generatenimbus/UIComponent.java
! make/src/classes/build/tools/generatenimbus/UIDefault.java
! make/src/classes/build/tools/generatenimbus/UIFont.java
! make/src/classes/build/tools/generatenimbus/UIIconRegion.java
! make/src/classes/build/tools/generatenimbus/UIProperty.java
! make/src/classes/build/tools/generatenimbus/UIRegion.java
! make/src/classes/build/tools/generatenimbus/UIState.java
! make/src/classes/build/tools/generatenimbus/UIStateType.java
! make/src/classes/build/tools/generatenimbus/UIStyle.java
! make/src/classes/build/tools/generatenimbus/Utils.java
! make/src/classes/build/tools/hasher/Hasher.java
! make/src/classes/build/tools/icondata/osxapp/ToBin.java
! make/src/classes/build/tools/jarreorder/JarReorder.java
! make/src/classes/build/tools/jdwpgen/AbstractCommandNode.java
! make/src/classes/build/tools/jdwpgen/AbstractGroupNode.java
! make/src/classes/build/tools/jdwpgen/AbstractNamedNode.java
! make/src/classes/build/tools/jdwpgen/AbstractSimpleNode.java
! make/src/classes/build/tools/jdwpgen/AbstractSimpleTypeNode.java
! make/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java
! make/src/classes/build/tools/jdwpgen/AbstractTypeNode.java
! make/src/classes/build/tools/jdwpgen/AltNode.java
! make/src/classes/build/tools/jdwpgen/ArrayObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ArrayRegionTypeNode.java
! make/src/classes/build/tools/jdwpgen/ArrayTypeNode.java
! make/src/classes/build/tools/jdwpgen/BooleanTypeNode.java
! make/src/classes/build/tools/jdwpgen/ByteTypeNode.java
! make/src/classes/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ClassObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ClassTypeNode.java
! make/src/classes/build/tools/jdwpgen/CommandNode.java
! make/src/classes/build/tools/jdwpgen/CommandSetNode.java
! make/src/classes/build/tools/jdwpgen/CommentNode.java
! make/src/classes/build/tools/jdwpgen/ConstantNode.java
! make/src/classes/build/tools/jdwpgen/ConstantSetNode.java
! make/src/classes/build/tools/jdwpgen/Context.java
! make/src/classes/build/tools/jdwpgen/ErrorNode.java
! make/src/classes/build/tools/jdwpgen/ErrorSetNode.java
! make/src/classes/build/tools/jdwpgen/EventNode.java
! make/src/classes/build/tools/jdwpgen/FieldTypeNode.java
! make/src/classes/build/tools/jdwpgen/FrameTypeNode.java
! make/src/classes/build/tools/jdwpgen/GroupNode.java
! make/src/classes/build/tools/jdwpgen/IntTypeNode.java
! make/src/classes/build/tools/jdwpgen/InterfaceTypeNode.java
! make/src/classes/build/tools/jdwpgen/LocationTypeNode.java
! make/src/classes/build/tools/jdwpgen/LongTypeNode.java
! make/src/classes/build/tools/jdwpgen/Main.java
! make/src/classes/build/tools/jdwpgen/MethodTypeNode.java
! make/src/classes/build/tools/jdwpgen/NameNode.java
! make/src/classes/build/tools/jdwpgen/NameValueNode.java
! make/src/classes/build/tools/jdwpgen/Node.java
! make/src/classes/build/tools/jdwpgen/ObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/OutNode.java
! make/src/classes/build/tools/jdwpgen/Parse.java
! make/src/classes/build/tools/jdwpgen/ReferenceIDTypeNode.java
! make/src/classes/build/tools/jdwpgen/ReferenceTypeNode.java
! make/src/classes/build/tools/jdwpgen/RepeatNode.java
! make/src/classes/build/tools/jdwpgen/ReplyNode.java
! make/src/classes/build/tools/jdwpgen/RootNode.java
! make/src/classes/build/tools/jdwpgen/SelectNode.java
! make/src/classes/build/tools/jdwpgen/StringObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/StringTypeNode.java
! make/src/classes/build/tools/jdwpgen/TaggedObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ThreadObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/TypeNode.java
! make/src/classes/build/tools/jdwpgen/UntaggedValueTypeNode.java
! make/src/classes/build/tools/jdwpgen/ValueTypeNode.java
! make/src/classes/build/tools/spp/Spp.java
! make/src/classes/build/tools/stripproperties/StripProperties.java
! make/src/classes/build/tools/swingbeaninfo/DocBeanInfo.java
! make/src/classes/build/tools/swingbeaninfo/GenDocletBeanInfo.java
! make/src/classes/build/tools/swingbeaninfo/GenSwingBeanInfo.java
! make/src/native/add_gnu_debuglink/add_gnu_debuglink.c
! make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
! src/macosx/bin/java_md_macosx.c
! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m
! src/macosx/classes/apple/applescript/AppleScriptEngine.java
! src/macosx/classes/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/apple/laf/JRSUIControl.java
! src/macosx/classes/apple/laf/JRSUIFocus.java
! src/macosx/classes/apple/laf/JRSUIState.java
! src/macosx/classes/apple/laf/JRSUIStateFactory.java
! src/macosx/classes/apple/laf/JRSUIUtils.java
! src/macosx/classes/com/apple/eawt/AboutHandler.java
! src/macosx/classes/com/apple/eawt/AppEvent.java
! src/macosx/classes/com/apple/eawt/AppEventListener.java
! src/macosx/classes/com/apple/eawt/AppForegroundListener.java
! src/macosx/classes/com/apple/eawt/AppHiddenListener.java
! src/macosx/classes/com/apple/eawt/AppReOpenedListener.java
! src/macosx/classes/com/apple/eawt/Application.java
! src/macosx/classes/com/apple/eawt/ApplicationAdapter.java
! src/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java
! src/macosx/classes/com/apple/eawt/ApplicationEvent.java
! src/macosx/classes/com/apple/eawt/ApplicationListener.java
! src/macosx/classes/com/apple/eawt/FullScreenAdapter.java
! src/macosx/classes/com/apple/eawt/FullScreenListener.java
! src/macosx/classes/com/apple/eawt/FullScreenUtilities.java
! src/macosx/classes/com/apple/eawt/OpenFilesHandler.java
! src/macosx/classes/com/apple/eawt/OpenURIHandler.java
! src/macosx/classes/com/apple/eawt/PreferencesHandler.java
! src/macosx/classes/com/apple/eawt/PrintFilesHandler.java
! src/macosx/classes/com/apple/eawt/QuitHandler.java
! src/macosx/classes/com/apple/eawt/QuitResponse.java
! src/macosx/classes/com/apple/eawt/QuitStrategy.java
! src/macosx/classes/com/apple/eawt/ScreenSleepListener.java
! src/macosx/classes/com/apple/eawt/SystemSleepListener.java
! src/macosx/classes/com/apple/eawt/UserSessionListener.java
! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java
! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java
! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/macosx/classes/com/apple/eawt/_AppMiscHandlers.java
! src/macosx/classes/com/apple/eawt/event/GestureAdapter.java
! src/macosx/classes/com/apple/eawt/event/GestureEvent.java
! src/macosx/classes/com/apple/eawt/event/GestureListener.java
! src/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java
! src/macosx/classes/com/apple/eawt/event/GesturePhaseListener.java
! src/macosx/classes/com/apple/eawt/event/GestureUtilities.java
! src/macosx/classes/com/apple/eawt/event/MagnificationEvent.java
! src/macosx/classes/com/apple/eawt/event/MagnificationListener.java
! src/macosx/classes/com/apple/eawt/event/RotationEvent.java
! src/macosx/classes/com/apple/eawt/event/RotationListener.java
! src/macosx/classes/com/apple/eawt/event/SwipeEvent.java
! src/macosx/classes/com/apple/eawt/event/SwipeListener.java
! src/macosx/classes/com/apple/laf/AquaBorder.java
! src/macosx/classes/com/apple/laf/AquaButtonBorder.java
! src/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java
! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java
! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java
! src/macosx/classes/com/apple/laf/AquaButtonRadioUI.java
! src/macosx/classes/com/apple/laf/AquaButtonToggleUI.java
! src/macosx/classes/com/apple/laf/AquaButtonUI.java
! src/macosx/classes/com/apple/laf/AquaCaret.java
! src/macosx/classes/com/apple/laf/AquaComboBoxButton.java
! src/macosx/classes/com/apple/laf/AquaComboBoxPopup.java
! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java
! src/macosx/classes/com/apple/laf/AquaEditorPaneUI.java
! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java
! src/macosx/classes/com/apple/laf/AquaFileSystemModel.java
! src/macosx/classes/com/apple/laf/AquaFileView.java
! src/macosx/classes/com/apple/laf/AquaFocus.java
! src/macosx/classes/com/apple/laf/AquaFocusHandler.java
! src/macosx/classes/com/apple/laf/AquaFonts.java
! src/macosx/classes/com/apple/laf/AquaGroupBorder.java
! src/macosx/classes/com/apple/laf/AquaHighlighter.java
! src/macosx/classes/com/apple/laf/AquaIcon.java
! src/macosx/classes/com/apple/laf/AquaImageFactory.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameBorderMetrics.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameDockIconUI.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameManager.java
! src/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java
! src/macosx/classes/com/apple/laf/AquaLabelUI.java
! src/macosx/classes/com/apple/laf/AquaListUI.java
! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/com/apple/laf/AquaMenuBarBorder.java
! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java
! src/macosx/classes/com/apple/laf/AquaMenuBorder.java
! src/macosx/classes/com/apple/laf/AquaMenuItemUI.java
! src/macosx/classes/com/apple/laf/AquaMenuPainter.java
! src/macosx/classes/com/apple/laf/AquaMenuUI.java
! src/macosx/classes/com/apple/laf/AquaMnemonicHandler.java
! src/macosx/classes/com/apple/laf/AquaNativeResources.java
! src/macosx/classes/com/apple/laf/AquaOptionPaneUI.java
! src/macosx/classes/com/apple/laf/AquaPanelUI.java
! src/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java
! src/macosx/classes/com/apple/laf/AquaPopupMenuUI.java
! src/macosx/classes/com/apple/laf/AquaProgressBarUI.java
! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java
! src/macosx/classes/com/apple/laf/AquaScrollBarUI.java
! src/macosx/classes/com/apple/laf/AquaScrollPaneUI.java
! src/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java
! src/macosx/classes/com/apple/laf/AquaSliderUI.java
! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java
! src/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java
! src/macosx/classes/com/apple/laf/AquaSplitPaneUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
! src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java
! src/macosx/classes/com/apple/laf/AquaTableHeaderUI.java
! src/macosx/classes/com/apple/laf/AquaTableUI.java
! src/macosx/classes/com/apple/laf/AquaTextAreaUI.java
! src/macosx/classes/com/apple/laf/AquaTextFieldBorder.java
! src/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java
! src/macosx/classes/com/apple/laf/AquaTextFieldSearch.java
! src/macosx/classes/com/apple/laf/AquaTextFieldUI.java
! src/macosx/classes/com/apple/laf/AquaTextPaneUI.java
! src/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java
! src/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java
! src/macosx/classes/com/apple/laf/AquaToolBarUI.java
! src/macosx/classes/com/apple/laf/AquaToolTipUI.java
! src/macosx/classes/com/apple/laf/AquaTreeUI.java
! src/macosx/classes/com/apple/laf/AquaUtilControlSize.java
! src/macosx/classes/com/apple/laf/ClientPropertyApplicator.java
! src/macosx/classes/com/apple/laf/ScreenMenuBar.java
! src/macosx/classes/com/apple/laf/ScreenMenuBarProvider.java
! src/macosx/classes/com/apple/laf/ScreenMenuItem.java
! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java
! src/macosx/classes/com/apple/laf/ScreenMenuItemUI.java
! src/macosx/classes/com/apple/laf/ScreenMenuPropertyHandler.java
! src/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java
! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java
! src/macosx/classes/com/apple/laf/resources/aqua.properties
! src/macosx/classes/com/apple/laf/resources/aqua_de.properties
! src/macosx/classes/com/apple/laf/resources/aqua_es.properties
! src/macosx/classes/com/apple/laf/resources/aqua_fr.properties
! src/macosx/classes/com/apple/laf/resources/aqua_it.properties
! src/macosx/classes/com/apple/laf/resources/aqua_ja.properties
! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties
! src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties
! src/macosx/classes/com/apple/laf/resources/aqua_sv.properties
! src/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
! src/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
! src/macosx/classes/java/net/DefaultInterface.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/classes/sun/awt/CGraphicsConfig.java
! src/macosx/classes/sun/awt/FullScreenCapable.java
! src/macosx/classes/sun/awt/fontconfigs/macosx.fontconfig.properties
! src/macosx/classes/sun/font/CCharToGlyphMapper.java
! src/macosx/classes/sun/font/CFont.java
! src/macosx/classes/sun/font/CFontConfiguration.java
! src/macosx/classes/sun/font/CFontManager.java
! src/macosx/classes/sun/font/CStrikeDisposer.java
! src/macosx/classes/sun/java2d/BackBufferCapsProvider.java
! src/macosx/classes/sun/java2d/CRenderer.java
! src/macosx/classes/sun/java2d/CompositeCRenderer.java
! src/macosx/classes/sun/java2d/DataBufferNIOInt.java
! src/macosx/classes/sun/java2d/IntegerNIORaster.java
! src/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java
! src/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
! src/macosx/classes/sun/lwawt/PlatformComponent.java
! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java
! src/macosx/classes/sun/lwawt/macosx/CAccessible.java
! src/macosx/classes/sun/lwawt/macosx/CAccessibleText.java
! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
! src/macosx/classes/sun/lwawt/macosx/CCustomCursor.java
! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java
! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java
! src/macosx/classes/sun/lwawt/macosx/CImage.java
! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java
! src/macosx/classes/sun/lwawt/macosx/CMenu.java
! src/macosx/classes/sun/lwawt/macosx/CMenuBar.java
! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java
! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java
! src/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPopupMenu.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDevice.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphics.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphicsConfig.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterJobDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterPageDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterSurfaceData.java
! src/macosx/classes/sun/lwawt/macosx/CRobot.java
! src/macosx/classes/sun/lwawt/macosx/CSystemTray.java
! src/macosx/classes/sun/lwawt/macosx/CTextPipe.java
! src/macosx/classes/sun/lwawt/macosx/CThreading.java
! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java
! src/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java
! src/macosx/classes/sun/lwawt/macosx/event/NSEvent.java
! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/macosx/native/com/apple/laf/AquaFileView.m
! src/macosx/native/com/apple/laf/AquaLookAndFeel.m
! src/macosx/native/com/apple/laf/AquaNativeResources.m
! src/macosx/native/com/apple/laf/JRSUIConstantSync.h
! src/macosx/native/com/apple/laf/JRSUIConstantSync.m
! src/macosx/native/com/apple/laf/JRSUIFocus.m
! src/macosx/native/com/apple/laf/ScreenMenu.h
! src/macosx/native/com/apple/laf/ScreenMenu.m
! src/macosx/native/com/apple/laf/ScreenPopupFactory.m
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiIn.c
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiOut.c
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.c
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.h
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.cpp
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.h
! src/macosx/native/java/util/SCDynamicStoreConfig.m
! src/macosx/native/jobjc/src/core/native/SEL.m
! src/macosx/native/sun/awt/AWTSurfaceLayers.h
! src/macosx/native/sun/awt/AWTView.h
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/ApplicationDelegate.h
! src/macosx/native/sun/awt/ApplicationDelegate.m
! src/macosx/native/sun/awt/CClipboard.h
! src/macosx/native/sun/awt/CClipboard.m
! src/macosx/native/sun/awt/CCursorManager.m
! src/macosx/native/sun/awt/CDataTransferer.h
! src/macosx/native/sun/awt/CDataTransferer.m
! src/macosx/native/sun/awt/CDesktopPeer.m
! src/macosx/native/sun/awt/CDragSource.h
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CDropTarget.h
! src/macosx/native/sun/awt/CDropTarget.m
! src/macosx/native/sun/awt/CDropTargetContextPeer.m
! src/macosx/native/sun/awt/CFRetainedResource.m
! src/macosx/native/sun/awt/CFileDialog.h
! src/macosx/native/sun/awt/CGraphicsConfig.m
! src/macosx/native/sun/awt/CGraphicsEnv.m
! src/macosx/native/sun/awt/CImage.m
! src/macosx/native/sun/awt/CInputMethod.m
! src/macosx/native/sun/awt/CMenu.h
! src/macosx/native/sun/awt/CMenu.m
! src/macosx/native/sun/awt/CMenuBar.h
! src/macosx/native/sun/awt/CMenuBar.m
! src/macosx/native/sun/awt/CMenuComponent.h
! src/macosx/native/sun/awt/CMenuComponent.m
! src/macosx/native/sun/awt/CMenuItem.h
! src/macosx/native/sun/awt/CPopupMenu.h
! src/macosx/native/sun/awt/CPopupMenu.m
! src/macosx/native/sun/awt/CPrinterJob.m
! src/macosx/native/sun/awt/CRobot.m
! src/macosx/native/sun/awt/CSystemColors.h
! src/macosx/native/sun/awt/CSystemColors.m
! src/macosx/native/sun/awt/CTextPipe.m
! src/macosx/native/sun/awt/CTrayIcon.h
! src/macosx/native/sun/awt/CTrayIcon.m
! src/macosx/native/sun/awt/CWrapper.h
! src/macosx/native/sun/awt/DnDUtilities.h
! src/macosx/native/sun/awt/DnDUtilities.m
! src/macosx/native/sun/awt/GeomUtilities.h
! src/macosx/native/sun/awt/GeomUtilities.m
! src/macosx/native/sun/awt/ImageSurfaceData.h
! src/macosx/native/sun/awt/ImageSurfaceData.m
! src/macosx/native/sun/awt/InitIDs.h
! src/macosx/native/sun/awt/InitIDs.m
! src/macosx/native/sun/awt/JavaAccessibilityAction.h
! src/macosx/native/sun/awt/JavaAccessibilityAction.m
! src/macosx/native/sun/awt/JavaAccessibilityUtilities.h
! src/macosx/native/sun/awt/JavaAccessibilityUtilities.m
! src/macosx/native/sun/awt/JavaComponentAccessibility.h
! src/macosx/native/sun/awt/JavaComponentAccessibility.m
! src/macosx/native/sun/awt/JavaTextAccessibility.h
! src/macosx/native/sun/awt/JavaTextAccessibility.m
! src/macosx/native/sun/awt/LWCToolkit.h
! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/awt/OSVersion.h
! src/macosx/native/sun/awt/OSVersion.m
! src/macosx/native/sun/awt/PrintModel.h
! src/macosx/native/sun/awt/PrintModel.m
! src/macosx/native/sun/awt/PrinterSurfaceData.h
! src/macosx/native/sun/awt/PrinterSurfaceData.m
! src/macosx/native/sun/awt/PrinterView.h
! src/macosx/native/sun/awt/QuartzRenderer.m
! src/macosx/native/sun/awt/QuartzSurfaceData.h
! src/macosx/native/sun/awt/QuartzSurfaceData.m
! src/macosx/native/sun/awt/awt.m
! src/macosx/native/sun/awt/awt_DrawingSurface.m
! src/macosx/native/sun/awt/jawt.m
! src/macosx/native/sun/awt/splashscreen/splashscreen_config.h
! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
! src/macosx/native/sun/font/AWTFont.h
! src/macosx/native/sun/font/AWTFont.m
! src/macosx/native/sun/font/CCharToGlyphMapper.m
! src/macosx/native/sun/font/CGGlyphImages.h
! src/macosx/native/sun/font/CGGlyphOutlines.h
! src/macosx/native/sun/font/CGGlyphOutlines.m
! src/macosx/native/sun/font/CoreTextSupport.h
! src/macosx/native/sun/font/CoreTextSupport.m
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.h
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.h
! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h
! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m
! src/macosx/native/sun/java2d/opengl/J2D_GL/cglext.h
! src/macosx/native/sun/java2d/opengl/OGLFuncs_md.h
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m
! src/macosx/native/sun/osxapp/ThreadUtilities.h
! src/macosx/native/sun/osxapp/ThreadUtilities.m
! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! src/share/back/SDE.c
! src/share/back/ThreadGroupReferenceImpl.c
! src/share/back/commonRef.c
! src/share/back/eventFilter.c
! src/share/back/export/sys.h
! src/share/back/outStream.c
! src/share/back/transport.c
! src/share/back/util.c
! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java
! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java
! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java
! src/share/classes/com/sun/beans/decoder/CharElementHandler.java
! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java
! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java
! src/share/classes/com/sun/beans/decoder/ElementHandler.java
! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java
! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java
! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java
! src/share/classes/com/sun/beans/decoder/IntElementHandler.java
! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java
! src/share/classes/com/sun/beans/decoder/LongElementHandler.java
! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java
! src/share/classes/com/sun/beans/decoder/NewElementHandler.java
! src/share/classes/com/sun/beans/decoder/NullElementHandler.java
! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java
! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java
! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java
! src/share/classes/com/sun/beans/decoder/StringElementHandler.java
! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java
! src/share/classes/com/sun/beans/decoder/VarElementHandler.java
! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java
! src/share/classes/com/sun/beans/finder/Signature.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
! src/share/classes/com/sun/crypto/provider/PCBC.java
! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java
! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java
! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java
! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java
! src/share/classes/com/sun/java/util/jar/pack/Code.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/jdi/AbsentInformationException.java
! src/share/classes/com/sun/jdi/Accessible.java
! src/share/classes/com/sun/jdi/ArrayReference.java
! src/share/classes/com/sun/jdi/ArrayType.java
! src/share/classes/com/sun/jdi/BooleanType.java
! src/share/classes/com/sun/jdi/BooleanValue.java
! src/share/classes/com/sun/jdi/Bootstrap.java
! src/share/classes/com/sun/jdi/ByteType.java
! src/share/classes/com/sun/jdi/ByteValue.java
! src/share/classes/com/sun/jdi/CharType.java
! src/share/classes/com/sun/jdi/CharValue.java
! src/share/classes/com/sun/jdi/ClassLoaderReference.java
! src/share/classes/com/sun/jdi/ClassNotLoadedException.java
! src/share/classes/com/sun/jdi/ClassNotPreparedException.java
! src/share/classes/com/sun/jdi/ClassObjectReference.java
! src/share/classes/com/sun/jdi/ClassType.java
! src/share/classes/com/sun/jdi/DoubleType.java
! src/share/classes/com/sun/jdi/DoubleValue.java
! src/share/classes/com/sun/jdi/Field.java
! src/share/classes/com/sun/jdi/FloatType.java
! src/share/classes/com/sun/jdi/FloatValue.java
! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java
! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java
! src/share/classes/com/sun/jdi/IntegerType.java
! src/share/classes/com/sun/jdi/IntegerValue.java
! src/share/classes/com/sun/jdi/InterfaceType.java
! src/share/classes/com/sun/jdi/InternalException.java
! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java
! src/share/classes/com/sun/jdi/InvalidLineNumberException.java
! src/share/classes/com/sun/jdi/InvalidStackFrameException.java
! src/share/classes/com/sun/jdi/InvalidTypeException.java
! src/share/classes/com/sun/jdi/InvocationException.java
! src/share/classes/com/sun/jdi/JDIPermission.java
! src/share/classes/com/sun/jdi/LocalVariable.java
! src/share/classes/com/sun/jdi/Locatable.java
! src/share/classes/com/sun/jdi/Location.java
! src/share/classes/com/sun/jdi/LongType.java
! src/share/classes/com/sun/jdi/LongValue.java
! src/share/classes/com/sun/jdi/Method.java
! src/share/classes/com/sun/jdi/Mirror.java
! src/share/classes/com/sun/jdi/MonitorInfo.java
! src/share/classes/com/sun/jdi/NativeMethodException.java
! src/share/classes/com/sun/jdi/ObjectCollectedException.java
! src/share/classes/com/sun/jdi/ObjectReference.java
! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java
! src/share/classes/com/sun/jdi/PrimitiveType.java
! src/share/classes/com/sun/jdi/PrimitiveValue.java
! src/share/classes/com/sun/jdi/ReferenceType.java
! src/share/classes/com/sun/jdi/ShortType.java
! src/share/classes/com/sun/jdi/ShortValue.java
! src/share/classes/com/sun/jdi/StackFrame.java
! src/share/classes/com/sun/jdi/StringReference.java
! src/share/classes/com/sun/jdi/ThreadGroupReference.java
! src/share/classes/com/sun/jdi/ThreadReference.java
! src/share/classes/com/sun/jdi/Type.java
! src/share/classes/com/sun/jdi/TypeComponent.java
! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java
! src/share/classes/com/sun/jdi/VMDisconnectedException.java
! src/share/classes/com/sun/jdi/VMMismatchException.java
! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java
! src/share/classes/com/sun/jdi/Value.java
! src/share/classes/com/sun/jdi/VirtualMachine.java
! src/share/classes/com/sun/jdi/VirtualMachineManager.java
! src/share/classes/com/sun/jdi/VoidType.java
! src/share/classes/com/sun/jdi/VoidValue.java
! src/share/classes/com/sun/jdi/connect/AttachingConnector.java
! src/share/classes/com/sun/jdi/connect/Connector.java
! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java
! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java
! src/share/classes/com/sun/jdi/connect/ListeningConnector.java
! src/share/classes/com/sun/jdi/connect/Transport.java
! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java
! src/share/classes/com/sun/jdi/connect/VMStartException.java
! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java
! src/share/classes/com/sun/jdi/connect/spi/Connection.java
! src/share/classes/com/sun/jdi/connect/spi/TransportService.java
! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java
! src/share/classes/com/sun/jdi/event/BreakpointEvent.java
! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java
! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java
! src/share/classes/com/sun/jdi/event/Event.java
! src/share/classes/com/sun/jdi/event/EventIterator.java
! src/share/classes/com/sun/jdi/event/EventQueue.java
! src/share/classes/com/sun/jdi/event/EventSet.java
! src/share/classes/com/sun/jdi/event/ExceptionEvent.java
! src/share/classes/com/sun/jdi/event/LocatableEvent.java
! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java
! src/share/classes/com/sun/jdi/event/MethodExitEvent.java
! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java
! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java
! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java
! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java
! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java
! src/share/classes/com/sun/jdi/event/StepEvent.java
! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java
! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java
! src/share/classes/com/sun/jdi/event/VMDeathEvent.java
! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java
! src/share/classes/com/sun/jdi/event/VMStartEvent.java
! src/share/classes/com/sun/jdi/event/WatchpointEvent.java
! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java
! src/share/classes/com/sun/jdi/request/BreakpointRequest.java
! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java
! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java
! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java
! src/share/classes/com/sun/jdi/request/EventRequest.java
! src/share/classes/com/sun/jdi/request/EventRequestManager.java
! src/share/classes/com/sun/jdi/request/ExceptionRequest.java
! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java
! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java
! src/share/classes/com/sun/jdi/request/MethodExitRequest.java
! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java
! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java
! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java
! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java
! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java
! src/share/classes/com/sun/jdi/request/StepRequest.java
! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java
! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java
! src/share/classes/com/sun/jdi/request/VMDeathRequest.java
! src/share/classes/com/sun/jdi/request/WatchpointRequest.java
! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java
! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java
! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java
! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java
! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java
! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java
! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java
! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java
! src/share/classes/com/sun/jmx/snmp/Enumerated.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java
! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java
! src/share/classes/com/sun/jmx/snmp/SnmpString.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java
! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java
! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java
! src/share/classes/com/sun/jndi/dns/DnsContext.java
! src/share/classes/com/sun/jndi/ldap/BasicControl.java
! src/share/classes/com/sun/jndi/ldap/BerDecoder.java
! src/share/classes/com/sun/jndi/ldap/BerEncoder.java
! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/Filter.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java
! src/share/classes/com/sun/jndi/ldap/LdapName.java
! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java
! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java
! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java
! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java
! src/share/classes/com/sun/management/GarbageCollectorMXBean.java
! src/share/classes/com/sun/management/GcInfo.java
! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java
! src/share/classes/com/sun/management/OperatingSystemMXBean.java
! src/share/classes/com/sun/management/ThreadMXBean.java
! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java
! src/share/classes/com/sun/management/VMOption.java
! src/share/classes/com/sun/media/sound/FastSysexMessage.java
! src/share/classes/com/sun/media/sound/SunFileReader.java
! src/share/classes/com/sun/naming/internal/ResourceManager.java
! src/share/classes/com/sun/net/httpserver/Authenticator.java
! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java
! src/share/classes/com/sun/net/httpserver/Filter.java
! src/share/classes/com/sun/net/httpserver/Headers.java
! src/share/classes/com/sun/net/httpserver/HttpContext.java
! src/share/classes/com/sun/net/httpserver/HttpExchange.java
! src/share/classes/com/sun/net/httpserver/HttpHandler.java
! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java
! src/share/classes/com/sun/net/httpserver/HttpServer.java
! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java
! src/share/classes/com/sun/net/httpserver/HttpsExchange.java
! src/share/classes/com/sun/net/httpserver/HttpsParameters.java
! src/share/classes/com/sun/net/httpserver/HttpsServer.java
! src/share/classes/com/sun/net/httpserver/package-info.java
! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java
! src/share/classes/com/sun/net/httpserver/spi/package-info.java
! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java
! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java
! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java
! src/share/classes/com/sun/nio/sctp/Association.java
! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java
! src/share/classes/com/sun/nio/sctp/HandlerResult.java
! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java
! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java
! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/Notification.java
! src/share/classes/com/sun/nio/sctp/NotificationHandler.java
! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java
! src/share/classes/com/sun/nio/sctp/SctpChannel.java
! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java
! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java
! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java
! src/share/classes/com/sun/nio/sctp/SendFailedNotification.java
! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java
! src/share/classes/com/sun/nio/sctp/package-info.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java
! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/BaseRow.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/package.html
! src/share/classes/com/sun/security/auth/LdapPrincipal.java
! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java
! src/share/classes/com/sun/security/auth/NTNumericCredential.java
! src/share/classes/com/sun/security/auth/NTSid.java
! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java
! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java
! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java
! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java
! src/share/classes/com/sun/security/auth/NTUserPrincipal.java
! src/share/classes/com/sun/security/auth/PrincipalComparator.java
! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java
! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java
! src/share/classes/com/sun/security/auth/SolarisPrincipal.java
! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java
! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java
! src/share/classes/com/sun/security/auth/UnixPrincipal.java
! src/share/classes/com/sun/security/auth/UserPrincipal.java
! src/share/classes/com/sun/security/auth/X500Principal.java
! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java
! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java
! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java
! src/share/classes/com/sun/security/auth/module/NTLoginModule.java
! src/share/classes/com/sun/security/auth/module/NTSystem.java
! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java
! src/share/classes/com/sun/security/auth/module/SolarisSystem.java
! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java
! src/share/classes/com/sun/security/auth/module/UnixSystem.java
! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java
! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java
! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java
! src/share/classes/com/sun/security/jgss/GSSUtil.java
! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java
! src/share/classes/com/sun/security/jgss/InquireType.java
! src/share/classes/com/sun/security/ntlm/Client.java
! src/share/classes/com/sun/security/ntlm/NTLM.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
! src/share/classes/com/sun/tools/attach/AgentInitializationException.java
! src/share/classes/com/sun/tools/attach/AgentLoadException.java
! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java
! src/share/classes/com/sun/tools/attach/AttachPermission.java
! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java
! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java
! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java
! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java
! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java
! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java
! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java
! src/share/classes/com/sun/tools/hat/resources/hat.js
! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html
! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java
! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java
! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java
! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/com/sun/tools/jdi/SDE.java
! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java
! src/share/classes/com/sun/tools/jdi/ThreadListener.java
! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/share/classes/com/sun/tools/script/shell/messages.properties
! src/share/classes/java/applet/Applet.java
! src/share/classes/java/applet/AppletStub.java
! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/AWTEventMulticaster.java
! src/share/classes/java/awt/AWTKeyStroke.java
! src/share/classes/java/awt/AWTPermission.java
! src/share/classes/java/awt/AttributeValue.java
! src/share/classes/java/awt/BorderLayout.java
! src/share/classes/java/awt/BufferCapabilities.java
! src/share/classes/java/awt/Button.java
! src/share/classes/java/awt/CardLayout.java
! src/share/classes/java/awt/Checkbox.java
! src/share/classes/java/awt/CheckboxGroup.java
! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Color.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/Cursor.java
! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/Event.java
! src/share/classes/java/awt/EventFilter.java
! src/share/classes/java/awt/FlowLayout.java
! src/share/classes/java/awt/FocusTraversalPolicy.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/FontMetrics.java
! src/share/classes/java/awt/Frame.java
! src/share/classes/java/awt/GradientPaintContext.java
! src/share/classes/java/awt/Graphics.java
! src/share/classes/java/awt/Graphics2D.java
! src/share/classes/java/awt/GraphicsConfiguration.java
! src/share/classes/java/awt/GraphicsEnvironment.java
! src/share/classes/java/awt/GridBagConstraints.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/GridLayout.java
! src/share/classes/java/awt/ImageCapabilities.java
! src/share/classes/java/awt/Insets.java
! src/share/classes/java/awt/JobAttributes.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/Label.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/LinearGradientPaintContext.java
! src/share/classes/java/awt/MediaTracker.java
! src/share/classes/java/awt/Menu.java
! src/share/classes/java/awt/MenuBar.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/MenuItem.java
! src/share/classes/java/awt/MultipleGradientPaintContext.java
! src/share/classes/java/awt/PageAttributes.java
! src/share/classes/java/awt/Polygon.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/Rectangle.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/ScrollPane.java
! src/share/classes/java/awt/ScrollPaneAdjustable.java
! src/share/classes/java/awt/Scrollbar.java
! src/share/classes/java/awt/SequencedEvent.java
! src/share/classes/java/awt/Shape.java
! src/share/classes/java/awt/SplashScreen.java
! src/share/classes/java/awt/SystemTray.java
! src/share/classes/java/awt/TextArea.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/TexturePaintContext.java
! src/share/classes/java/awt/TrayIcon.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/java/awt/color/ICC_ColorSpace.java
! src/share/classes/java/awt/color/ICC_ProfileGray.java
! src/share/classes/java/awt/color/ICC_ProfileRGB.java
! src/share/classes/java/awt/color/package.html
! src/share/classes/java/awt/datatransfer/Clipboard.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/FlavorMap.java
! src/share/classes/java/awt/datatransfer/MimeType.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/java/awt/datatransfer/Transferable.java
! src/share/classes/java/awt/datatransfer/package.html
! src/share/classes/java/awt/dnd/DnDEventMulticaster.java
! src/share/classes/java/awt/dnd/DragGestureEvent.java
! src/share/classes/java/awt/dnd/DragGestureListener.java
! src/share/classes/java/awt/dnd/DragGestureRecognizer.java
! src/share/classes/java/awt/dnd/DragSource.java
! src/share/classes/java/awt/dnd/DragSourceContext.java
! src/share/classes/java/awt/dnd/DragSourceDragEvent.java
! src/share/classes/java/awt/dnd/DragSourceDropEvent.java
! src/share/classes/java/awt/dnd/DragSourceEvent.java
! src/share/classes/java/awt/dnd/DropTarget.java
! src/share/classes/java/awt/dnd/DropTargetDragEvent.java
! src/share/classes/java/awt/dnd/DropTargetDropEvent.java
! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java
! src/share/classes/java/awt/dnd/package.html
! src/share/classes/java/awt/doc-files/AWTThreadIssues.html
! src/share/classes/java/awt/doc-files/DesktopProperties.html
! src/share/classes/java/awt/doc-files/FocusSpec.html
! src/share/classes/java/awt/doc-files/Modality.html
! src/share/classes/java/awt/event/ActionListener.java
! src/share/classes/java/awt/event/ComponentAdapter.java
! src/share/classes/java/awt/event/ComponentListener.java
! src/share/classes/java/awt/event/ContainerAdapter.java
! src/share/classes/java/awt/event/ContainerEvent.java
! src/share/classes/java/awt/event/ContainerListener.java
! src/share/classes/java/awt/event/FocusAdapter.java
! src/share/classes/java/awt/event/FocusListener.java
! src/share/classes/java/awt/event/InputEvent.java
! src/share/classes/java/awt/event/InvocationEvent.java
! src/share/classes/java/awt/event/ItemEvent.java
! src/share/classes/java/awt/event/ItemListener.java
! src/share/classes/java/awt/event/KeyAdapter.java
! src/share/classes/java/awt/event/KeyEvent.java
! src/share/classes/java/awt/event/MouseAdapter.java
! src/share/classes/java/awt/event/MouseEvent.java
! src/share/classes/java/awt/event/MouseListener.java
! src/share/classes/java/awt/event/MouseMotionAdapter.java
! src/share/classes/java/awt/event/MouseMotionListener.java
! src/share/classes/java/awt/event/NativeLibLoader.java
! src/share/classes/java/awt/event/WindowAdapter.java
! src/share/classes/java/awt/event/WindowFocusListener.java
! src/share/classes/java/awt/event/WindowListener.java
! src/share/classes/java/awt/event/package.html
! src/share/classes/java/awt/font/FontRenderContext.java
! src/share/classes/java/awt/font/GlyphMetrics.java
! src/share/classes/java/awt/font/GlyphVector.java
! src/share/classes/java/awt/font/LineBreakMeasurer.java
! src/share/classes/java/awt/font/MultipleMaster.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/font/StyledParagraph.java
! src/share/classes/java/awt/font/TextAttribute.java
! src/share/classes/java/awt/font/TextLayout.java
! src/share/classes/java/awt/font/TextLine.java
! src/share/classes/java/awt/font/TextMeasurer.java
! src/share/classes/java/awt/font/TransformAttribute.java
! src/share/classes/java/awt/font/package.html
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/Arc2D.java
! src/share/classes/java/awt/geom/Dimension2D.java
! src/share/classes/java/awt/geom/FlatteningPathIterator.java
! src/share/classes/java/awt/geom/Line2D.java
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/java/awt/geom/Point2D.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/geom/RectangularShape.java
! src/share/classes/java/awt/geom/package.html
! src/share/classes/java/awt/im/InputContext.java
! src/share/classes/java/awt/im/InputMethodHighlight.java
! src/share/classes/java/awt/im/InputMethodRequests.java
! src/share/classes/java/awt/image/BandedSampleModel.java
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ByteLookupTable.java
! src/share/classes/java/awt/image/ColorConvertOp.java
! src/share/classes/java/awt/image/ColorModel.java
! src/share/classes/java/awt/image/ComponentColorModel.java
! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/java/awt/image/ImageFilter.java
! src/share/classes/java/awt/image/ImageProducer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/Kernel.java
! src/share/classes/java/awt/image/MemoryImageSource.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/image/PixelGrabber.java
! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java
! src/share/classes/java/awt/image/RGBImageFilter.java
! src/share/classes/java/awt/image/Raster.java
! src/share/classes/java/awt/image/SampleModel.java
! src/share/classes/java/awt/image/ShortLookupTable.java
! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/share/classes/java/awt/image/WritableRaster.java
! src/share/classes/java/awt/image/package.html
! src/share/classes/java/awt/image/renderable/RenderableImage.java
! src/share/classes/java/awt/image/renderable/RenderableImageOp.java
! src/share/classes/java/awt/image/renderable/package.html
! src/share/classes/java/awt/package.html
! src/share/classes/java/awt/peer/CheckboxPeer.java
! src/share/classes/java/awt/peer/DesktopPeer.java
! src/share/classes/java/awt/peer/FramePeer.java
! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java
! src/share/classes/java/awt/peer/TextComponentPeer.java
! src/share/classes/java/awt/print/Book.java
! src/share/classes/java/awt/print/PrinterJob.java
! src/share/classes/java/awt/print/package.html
! src/share/classes/java/beans/BeanDescriptor.java
! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/FeatureDescriptor.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/NameGenerator.java
! src/share/classes/java/beans/PropertyEditorManager.java
! src/share/classes/java/beans/PropertyEditorSupport.java
! src/share/classes/java/beans/SimpleBeanInfo.java
! src/share/classes/java/beans/XMLEncoder.java
! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java
! src/share/classes/java/io/BufferedWriter.java
! src/share/classes/java/io/ByteArrayInputStream.java
! src/share/classes/java/io/ByteArrayOutputStream.java
! src/share/classes/java/io/Console.java
! src/share/classes/java/io/DataOutput.java
! src/share/classes/java/io/EOFException.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/io/FileSystem.java
! src/share/classes/java/io/ObjectStreamConstants.java
! src/share/classes/java/io/PipedReader.java
! src/share/classes/java/io/PrintStream.java
! src/share/classes/java/io/PushbackInputStream.java
! src/share/classes/java/io/PushbackReader.java
! src/share/classes/java/io/Serializable.java
! src/share/classes/java/io/SerializablePermission.java
! src/share/classes/java/io/StringReader.java
! src/share/classes/java/lang/ArrayStoreException.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/ClassCastException.java
! src/share/classes/java/lang/ClassValue.java
! src/share/classes/java/lang/ConditionalSpecialCasing.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/ProcessBuilder.java
! src/share/classes/java/lang/RuntimePermission.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/StackTraceElement.java
! src/share/classes/java/lang/StringBuilder.java
! src/share/classes/java/lang/ThreadLocal.java
! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
! src/share/classes/java/lang/instrument/package.html
! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/ConstantCallSite.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/LambdaForm.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/invoke/MutableCallSite.java
! src/share/classes/java/lang/invoke/Stable.java
! src/share/classes/java/lang/invoke/SwitchPoint.java
! src/share/classes/java/lang/invoke/package-info.java
! src/share/classes/java/lang/management/CompilationMXBean.java
! src/share/classes/java/lang/management/ManagementPermission.java
! src/share/classes/java/lang/management/package.html
! src/share/classes/java/lang/reflect/Array.java
! src/share/classes/java/lang/reflect/Member.java
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/java/lang/reflect/Type.java
! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/share/classes/java/net/Inet4AddressImpl.java
! src/share/classes/java/net/Inet6AddressImpl.java
! src/share/classes/java/net/SocketAddress.java
! src/share/classes/java/net/StandardSocketOptions.java
! src/share/classes/java/nio/Buffer.java
! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
! src/share/classes/java/nio/ByteOrder.java
! src/share/classes/java/nio/Direct-X-Buffer.java.template
! src/share/classes/java/nio/Heap-X-Buffer.java.template
! src/share/classes/java/nio/MappedByteBuffer.java
! src/share/classes/java/nio/StringCharBuffer.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/channels/AsynchronousByteChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/Channel.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/channels/FileLock.java
! src/share/classes/java/nio/channels/MembershipKey.java
! src/share/classes/java/nio/channels/MulticastChannel.java
! src/share/classes/java/nio/channels/NetworkChannel.java
! src/share/classes/java/nio/channels/Pipe.java
! src/share/classes/java/nio/channels/SelectableChannel.java
! src/share/classes/java/nio/channels/SelectionKey.java
! src/share/classes/java/nio/channels/Selector.java
! src/share/classes/java/nio/channels/ServerSocketChannel.java
! src/share/classes/java/nio/channels/SocketChannel.java
! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelectionKey.java
! src/share/classes/java/nio/channels/spi/AbstractSelector.java
! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java
! src/share/classes/java/nio/channels/spi/SelectorProvider.java
! src/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/share/classes/java/nio/charset/CoderResult.java
! src/share/classes/java/nio/charset/CodingErrorAction.java
! src/share/classes/java/nio/charset/spi/CharsetProvider.java
! src/share/classes/java/nio/file/FileStore.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/FileSystems.java
! src/share/classes/java/nio/file/FileTreeWalker.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/nio/file/WatchEvent.java
! src/share/classes/java/nio/file/WatchService.java
! src/share/classes/java/nio/file/attribute/AclEntry.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/AttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java
! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileAttribute.java
! src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java
! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java
! src/share/classes/java/nio/file/spi/FileSystemProvider.java
! src/share/classes/java/nio/package.html
! src/share/classes/java/rmi/MarshalledObject.java
! src/share/classes/java/sql/Array.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DataTruncation.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/DriverPropertyInfo.java
! src/share/classes/java/sql/SQLException.java
! src/share/classes/java/sql/SQLFeatureNotSupportedException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLNonTransientException.java
! src/share/classes/java/sql/SQLRecoverableException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java
! src/share/classes/java/sql/SQLTransientException.java
! src/share/classes/java/sql/SQLWarning.java
! src/share/classes/java/sql/Struct.java
! src/share/classes/java/sql/Time.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/java/text/CharacterIterator.java
! src/share/classes/java/text/Collator.java
! src/share/classes/java/util/AbstractCollection.java
! src/share/classes/java/util/AbstractMap.java
! src/share/classes/java/util/AbstractSet.java
! src/share/classes/java/util/ArrayPrefixHelpers.java
! src/share/classes/java/util/ArraysParallelSortHelpers.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/ConcurrentModificationException.java
! src/share/classes/java/util/Date.java
! src/share/classes/java/util/DualPivotQuicksort.java
! src/share/classes/java/util/EnumSet.java
! src/share/classes/java/util/Formattable.java
! src/share/classes/java/util/ListResourceBundle.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/LocaleISOData.java
! src/share/classes/java/util/MissingFormatWidthException.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/PropertyResourceBundle.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/TimerTask.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/function/ToIntBiFunction.java
! src/share/classes/java/util/function/package-info.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
! src/share/classes/java/util/jar/Manifest.java
! src/share/classes/java/util/logging/ConsoleHandler.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/Level.java
! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/SimpleFormatter.java
! src/share/classes/java/util/logging/SocketHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
! src/share/classes/java/util/logging/XMLFormatter.java
! src/share/classes/java/util/prefs/Preferences.java
! src/share/classes/java/util/regex/UnicodeProp.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java
! src/share/classes/java/util/zip/DeflaterInputStream.java
! src/share/classes/java/util/zip/DeflaterOutputStream.java
! src/share/classes/java/util/zip/GZIPOutputStream.java
! src/share/classes/java/util/zip/InflaterInputStream.java
! src/share/classes/java/util/zip/InflaterOutputStream.java
! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipConstants64.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/javax/accessibility/AccessibleAction.java
! src/share/classes/javax/accessibility/AccessibleContext.java
! src/share/classes/javax/accessibility/AccessibleText.java
! src/share/classes/javax/crypto/JceSecurityManager.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/crypto/spec/IvParameterSpec.java
! src/share/classes/javax/crypto/spec/PBEParameterSpec.java
! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java
! src/share/classes/javax/crypto/spec/SecretKeySpec.java
! src/share/classes/javax/imageio/IIOParam.java
! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReadParam.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageTypeSpecifier.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/event/IIOReadProgressListener.java
! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java
! src/share/classes/javax/imageio/event/IIOReadWarningListener.java
! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java
! src/share/classes/javax/imageio/metadata/IIOMetadata.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java
! src/share/classes/javax/imageio/spi/IIORegistry.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/share/classes/javax/imageio/stream/ImageOutputStream.java
! src/share/classes/javax/management/AttributeList.java
! src/share/classes/javax/management/BadAttributeValueExpException.java
! src/share/classes/javax/management/BooleanValueExp.java
! src/share/classes/javax/management/Descriptor.java
! src/share/classes/javax/management/DescriptorKey.java
! src/share/classes/javax/management/ImmutableDescriptor.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanFeatureInfo.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanNotificationInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/MBeanServerConnection.java
! src/share/classes/javax/management/MBeanServerFactory.java
! src/share/classes/javax/management/MBeanServerInvocationHandler.java
! src/share/classes/javax/management/MBeanServerNotification.java
! src/share/classes/javax/management/MBeanTrustPermission.java
! src/share/classes/javax/management/MXBean.java
! src/share/classes/javax/management/NumericValueExp.java
! src/share/classes/javax/management/ObjectName.java
! src/share/classes/javax/management/PersistentMBean.java
! src/share/classes/javax/management/Query.java
! src/share/classes/javax/management/StandardEmitterMBean.java
! src/share/classes/javax/management/loading/MLet.java
! src/share/classes/javax/management/loading/MLetParser.java
! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java
! src/share/classes/javax/management/monitor/Monitor.java
! src/share/classes/javax/management/monitor/package.html
! src/share/classes/javax/management/openmbean/ArrayType.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/CompositeType.java
! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java
! src/share/classes/javax/management/openmbean/SimpleType.java
! src/share/classes/javax/management/openmbean/TabularType.java
! src/share/classes/javax/management/package.html
! src/share/classes/javax/management/relation/Relation.java
! src/share/classes/javax/management/relation/RelationService.java
! src/share/classes/javax/management/relation/RelationServiceMBean.java
! src/share/classes/javax/management/relation/RelationSupport.java
! src/share/classes/javax/management/remote/JMXConnectionNotification.java
! src/share/classes/javax/management/remote/JMXConnector.java
! src/share/classes/javax/management/remote/JMXConnectorFactory.java
! src/share/classes/javax/management/remote/JMXConnectorProvider.java
! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java
! src/share/classes/javax/management/remote/JMXPrincipal.java
! src/share/classes/javax/management/remote/JMXServiceURL.java
! src/share/classes/javax/management/remote/NotificationResult.java
! src/share/classes/javax/management/remote/TargetedNotification.java
! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java
! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java
! src/share/classes/javax/management/remote/rmi/package.html
! src/share/classes/javax/naming/BinaryRefAddr.java
! src/share/classes/javax/naming/Binding.java
! src/share/classes/javax/naming/InsufficientResourcesException.java
! src/share/classes/javax/naming/directory/Attribute.java
! src/share/classes/javax/naming/ldap/InitialLdapContext.java
! src/share/classes/javax/naming/ldap/LdapName.java
! src/share/classes/javax/naming/ldap/PagedResultsControl.java
! src/share/classes/javax/naming/ldap/SortControl.java
! src/share/classes/javax/net/ssl/HttpsURLConnection.java
! src/share/classes/javax/net/ssl/SSLContextSpi.java
! src/share/classes/javax/net/ssl/SSLEngineResult.java
! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java
! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java
! src/share/classes/javax/net/ssl/SSLSession.java
! src/share/classes/javax/net/ssl/SSLSessionContext.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/print/CancelablePrintJob.java
! src/share/classes/javax/print/Doc.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDoc.java
! src/share/classes/javax/print/MultiDocPrintJob.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/ServiceUI.java
! src/share/classes/javax/print/ServiceUIFactory.java
! src/share/classes/javax/print/attribute/AttributeSet.java
! src/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/share/classes/javax/print/attribute/DocAttributeSet.java
! src/share/classes/javax/print/attribute/EnumSyntax.java
! src/share/classes/javax/print/attribute/HashAttributeSet.java
! src/share/classes/javax/print/attribute/IntegerSyntax.java
! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java
! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java
! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java
! src/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/share/classes/javax/print/attribute/Size2DSyntax.java
! src/share/classes/javax/print/attribute/package.html
! src/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/share/classes/javax/print/attribute/standard/Compression.java
! src/share/classes/javax/print/attribute/standard/Finishings.java
! src/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/share/classes/javax/print/attribute/standard/JobStateReasons.java
! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/share/classes/javax/print/attribute/standard/MediaSize.java
! src/share/classes/javax/print/attribute/standard/MediaTray.java
! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java
! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/share/classes/javax/print/attribute/standard/PrinterResolution.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java
! src/share/classes/javax/print/attribute/standard/Sides.java
! src/share/classes/javax/print/attribute/standard/package.html
! src/share/classes/javax/print/event/package.html
! src/share/classes/javax/print/package.html
! src/share/classes/javax/script/AbstractScriptEngine.java
! src/share/classes/javax/script/CompiledScript.java
! src/share/classes/javax/script/ScriptEngine.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java
! src/share/classes/javax/smartcardio/CardChannel.java
! src/share/classes/javax/smartcardio/CardTerminal.java
! src/share/classes/javax/smartcardio/ResponseAPDU.java
! src/share/classes/javax/sound/midi/Soundbank.java
! src/share/classes/javax/sound/sampled/DataLine.java
! src/share/classes/javax/sound/sampled/ReverbType.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/StatementEvent.java
! src/share/classes/javax/sql/rowset/JoinRowSet.java
! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java
! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java
! src/share/classes/javax/sql/rowset/spi/XmlReader.java
! src/share/classes/javax/sql/rowset/spi/XmlWriter.java
! src/share/classes/javax/swing/AbstractAction.java
! src/share/classes/javax/swing/AbstractButton.java
! src/share/classes/javax/swing/AbstractCellEditor.java
! src/share/classes/javax/swing/AbstractListModel.java
! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/ActionMap.java
! src/share/classes/javax/swing/ActionPropertyChangeListener.java
! src/share/classes/javax/swing/ArrayTable.java
! src/share/classes/javax/swing/BorderFactory.java
! src/share/classes/javax/swing/BoundedRangeModel.java
! src/share/classes/javax/swing/Box.java
! src/share/classes/javax/swing/BoxLayout.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/ButtonGroup.java
! src/share/classes/javax/swing/CellRendererPane.java
! src/share/classes/javax/swing/ClientPropertyKey.java
! src/share/classes/javax/swing/ComboBoxModel.java
! src/share/classes/javax/swing/ComponentInputMap.java
! src/share/classes/javax/swing/DefaultBoundedRangeModel.java
! src/share/classes/javax/swing/DefaultButtonModel.java
! src/share/classes/javax/swing/DefaultCellEditor.java
! src/share/classes/javax/swing/DefaultFocusManager.java
! src/share/classes/javax/swing/DefaultListCellRenderer.java
! src/share/classes/javax/swing/DefaultListModel.java
! src/share/classes/javax/swing/DefaultListSelectionModel.java
! src/share/classes/javax/swing/DefaultRowSorter.java
! src/share/classes/javax/swing/DefaultSingleSelectionModel.java
! src/share/classes/javax/swing/DesktopManager.java
! src/share/classes/javax/swing/FocusManager.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/ImageIcon.java
! src/share/classes/javax/swing/InputMap.java
! src/share/classes/javax/swing/InputVerifier.java
! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/JButton.java
! src/share/classes/javax/swing/JCheckBox.java
! src/share/classes/javax/swing/JCheckBoxMenuItem.java
! src/share/classes/javax/swing/JColorChooser.java
! src/share/classes/javax/swing/JComboBox.java
! src/share/classes/javax/swing/JDesktopPane.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JEditorPane.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/JFormattedTextField.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JLabel.java
! src/share/classes/javax/swing/JLayer.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/JList.java
! src/share/classes/javax/swing/JMenu.java
! src/share/classes/javax/swing/JMenuBar.java
! src/share/classes/javax/swing/JMenuItem.java
! src/share/classes/javax/swing/JOptionPane.java
! src/share/classes/javax/swing/JPanel.java
! src/share/classes/javax/swing/JPasswordField.java
! src/share/classes/javax/swing/JProgressBar.java
! src/share/classes/javax/swing/JRadioButton.java
! src/share/classes/javax/swing/JRadioButtonMenuItem.java
! src/share/classes/javax/swing/JRootPane.java
! src/share/classes/javax/swing/JScrollBar.java
! src/share/classes/javax/swing/JScrollPane.java
! src/share/classes/javax/swing/JSeparator.java
! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/JSpinner.java
! src/share/classes/javax/swing/JSplitPane.java
! src/share/classes/javax/swing/JTabbedPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JTextArea.java
! src/share/classes/javax/swing/JTextField.java
! src/share/classes/javax/swing/JTextPane.java
! src/share/classes/javax/swing/JToggleButton.java
! src/share/classes/javax/swing/JToolBar.java
! src/share/classes/javax/swing/JToolTip.java
! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/JViewport.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/KeyStroke.java
! src/share/classes/javax/swing/KeyboardManager.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/MenuSelectionManager.java
! src/share/classes/javax/swing/MutableComboBoxModel.java
! src/share/classes/javax/swing/OverlayLayout.java
! src/share/classes/javax/swing/Painter.java
! src/share/classes/javax/swing/Popup.java
! src/share/classes/javax/swing/PopupFactory.java
! src/share/classes/javax/swing/ProgressMonitor.java
! src/share/classes/javax/swing/ProgressMonitorInputStream.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/javax/swing/RootPaneContainer.java
! src/share/classes/javax/swing/RowFilter.java
! src/share/classes/javax/swing/ScrollPaneConstants.java
! src/share/classes/javax/swing/ScrollPaneLayout.java
! src/share/classes/javax/swing/SizeRequirements.java
! src/share/classes/javax/swing/SizeSequence.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/javax/swing/SpinnerDateModel.java
! src/share/classes/javax/swing/SpinnerListModel.java
! src/share/classes/javax/swing/SpinnerModel.java
! src/share/classes/javax/swing/SpinnerNumberModel.java
! src/share/classes/javax/swing/Spring.java
! src/share/classes/javax/swing/SpringLayout.java
! src/share/classes/javax/swing/SwingUtilities.java
! src/share/classes/javax/swing/Timer.java
! src/share/classes/javax/swing/TimerQueue.java
! src/share/classes/javax/swing/ToolTipManager.java
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/javax/swing/UIDefaults.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java
! src/share/classes/javax/swing/ViewportLayout.java
! src/share/classes/javax/swing/WindowConstants.java
! src/share/classes/javax/swing/border/AbstractBorder.java
! src/share/classes/javax/swing/border/BevelBorder.java
! src/share/classes/javax/swing/border/Border.java
! src/share/classes/javax/swing/border/CompoundBorder.java
! src/share/classes/javax/swing/border/EmptyBorder.java
! src/share/classes/javax/swing/border/EtchedBorder.java
! src/share/classes/javax/swing/border/LineBorder.java
! src/share/classes/javax/swing/border/MatteBorder.java
! src/share/classes/javax/swing/border/SoftBevelBorder.java
! src/share/classes/javax/swing/border/TitledBorder.java
! src/share/classes/javax/swing/border/package.html
! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java
! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java
! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java
! src/share/classes/javax/swing/colorchooser/ColorPanel.java
! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java
! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java
! src/share/classes/javax/swing/colorchooser/package.html
! src/share/classes/javax/swing/event/AncestorEvent.java
! src/share/classes/javax/swing/event/CaretEvent.java
! src/share/classes/javax/swing/event/ChangeEvent.java
! src/share/classes/javax/swing/event/DocumentEvent.java
! src/share/classes/javax/swing/event/EventListenerList.java
! src/share/classes/javax/swing/event/HyperlinkEvent.java
! src/share/classes/javax/swing/event/InternalFrameAdapter.java
! src/share/classes/javax/swing/event/InternalFrameEvent.java
! src/share/classes/javax/swing/event/InternalFrameListener.java
! src/share/classes/javax/swing/event/ListDataEvent.java
! src/share/classes/javax/swing/event/ListSelectionEvent.java
! src/share/classes/javax/swing/event/MenuDragMouseEvent.java
! src/share/classes/javax/swing/event/MenuEvent.java
! src/share/classes/javax/swing/event/MenuKeyEvent.java
! src/share/classes/javax/swing/event/PopupMenuEvent.java
! src/share/classes/javax/swing/event/TableColumnModelEvent.java
! src/share/classes/javax/swing/event/TableModelEvent.java
! src/share/classes/javax/swing/event/TreeExpansionEvent.java
! src/share/classes/javax/swing/event/TreeExpansionListener.java
! src/share/classes/javax/swing/event/TreeModelEvent.java
! src/share/classes/javax/swing/event/TreeModelListener.java
! src/share/classes/javax/swing/event/TreeSelectionEvent.java
! src/share/classes/javax/swing/event/TreeSelectionListener.java
! src/share/classes/javax/swing/event/TreeWillExpandListener.java
! src/share/classes/javax/swing/event/UndoableEditEvent.java
! src/share/classes/javax/swing/event/package.html
! src/share/classes/javax/swing/filechooser/FileFilter.java
! src/share/classes/javax/swing/filechooser/FileSystemView.java
! src/share/classes/javax/swing/filechooser/FileView.java
! src/share/classes/javax/swing/filechooser/package.html
! src/share/classes/javax/swing/package.html
! src/share/classes/javax/swing/plaf/BorderUIResource.java
! src/share/classes/javax/swing/plaf/ColorUIResource.java
! src/share/classes/javax/swing/plaf/ComboBoxUI.java
! src/share/classes/javax/swing/plaf/ComponentUI.java
! src/share/classes/javax/swing/plaf/DimensionUIResource.java
! src/share/classes/javax/swing/plaf/FontUIResource.java
! src/share/classes/javax/swing/plaf/IconUIResource.java
! src/share/classes/javax/swing/plaf/InsetsUIResource.java
! src/share/classes/javax/swing/plaf/LayerUI.java
! src/share/classes/javax/swing/plaf/TextUI.java
! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java
! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java
! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java
! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java
! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java
! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java
! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java
! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java
! src/share/classes/javax/swing/plaf/basic/BasicListUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java
! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java
! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java
! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java
! src/share/classes/javax/swing/plaf/basic/ComboPopup.java
! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java
! src/share/classes/javax/swing/plaf/basic/package.html
! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java
! src/share/classes/javax/swing/plaf/metal/MetalBorders.java
! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java
! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java
! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java
! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java
! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java
! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java
! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java
! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java
! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java
! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java
! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java
! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java
! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java
! src/share/classes/javax/swing/plaf/metal/package.html
! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java
! src/share/classes/javax/swing/plaf/multi/package.html
! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
! src/share/classes/javax/swing/plaf/nimbus/package.html
! src/share/classes/javax/swing/plaf/package.html
! src/share/classes/javax/swing/plaf/synth/Region.java
! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java
! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthComboPopup.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthListUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPainter.java
! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java
! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/share/classes/javax/swing/plaf/synth/package.html
! src/share/classes/javax/swing/table/AbstractTableModel.java
! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java
! src/share/classes/javax/swing/table/DefaultTableColumnModel.java
! src/share/classes/javax/swing/table/DefaultTableModel.java
! src/share/classes/javax/swing/table/JTableHeader.java
! src/share/classes/javax/swing/table/TableCellRenderer.java
! src/share/classes/javax/swing/table/TableColumn.java
! src/share/classes/javax/swing/table/TableColumnModel.java
! src/share/classes/javax/swing/table/TableModel.java
! src/share/classes/javax/swing/table/package.html
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/javax/swing/text/AbstractWriter.java
! src/share/classes/javax/swing/text/AsyncBoxView.java
! src/share/classes/javax/swing/text/AttributeSet.java
! src/share/classes/javax/swing/text/BadLocationException.java
! src/share/classes/javax/swing/text/BoxView.java
! src/share/classes/javax/swing/text/Caret.java
! src/share/classes/javax/swing/text/ComponentView.java
! src/share/classes/javax/swing/text/CompositeView.java
! src/share/classes/javax/swing/text/DateFormatter.java
! src/share/classes/javax/swing/text/DefaultCaret.java
! src/share/classes/javax/swing/text/DefaultEditorKit.java
! src/share/classes/javax/swing/text/DefaultFormatter.java
! src/share/classes/javax/swing/text/DefaultFormatterFactory.java
! src/share/classes/javax/swing/text/DefaultHighlighter.java
! src/share/classes/javax/swing/text/DefaultStyledDocument.java
! src/share/classes/javax/swing/text/Document.java
! src/share/classes/javax/swing/text/DocumentFilter.java
! src/share/classes/javax/swing/text/EditorKit.java
! src/share/classes/javax/swing/text/Element.java
! src/share/classes/javax/swing/text/ElementIterator.java
! src/share/classes/javax/swing/text/FieldView.java
! src/share/classes/javax/swing/text/GapContent.java
! src/share/classes/javax/swing/text/GapVector.java
! src/share/classes/javax/swing/text/GlyphPainter2.java
! src/share/classes/javax/swing/text/Highlighter.java
! src/share/classes/javax/swing/text/IconView.java
! src/share/classes/javax/swing/text/InternationalFormatter.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/MaskFormatter.java
! src/share/classes/javax/swing/text/NavigationFilter.java
! src/share/classes/javax/swing/text/NumberFormatter.java
! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/classes/javax/swing/text/PasswordView.java
! src/share/classes/javax/swing/text/PlainDocument.java
! src/share/classes/javax/swing/text/PlainView.java
! src/share/classes/javax/swing/text/Position.java
! src/share/classes/javax/swing/text/StringContent.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/StyleContext.java
! src/share/classes/javax/swing/text/StyledDocument.java
! src/share/classes/javax/swing/text/StyledEditorKit.java
! src/share/classes/javax/swing/text/TabExpander.java
! src/share/classes/javax/swing/text/TabSet.java
! src/share/classes/javax/swing/text/TabStop.java
! src/share/classes/javax/swing/text/TabableView.java
! src/share/classes/javax/swing/text/TableView.java
! src/share/classes/javax/swing/text/TextAction.java
! src/share/classes/javax/swing/text/Utilities.java
! src/share/classes/javax/swing/text/WrappedPlainView.java
! src/share/classes/javax/swing/text/ZoneView.java
! src/share/classes/javax/swing/text/html/AccessibleHTML.java
! src/share/classes/javax/swing/text/html/BlockView.java
! src/share/classes/javax/swing/text/html/CSS.java
! src/share/classes/javax/swing/text/html/CSSParser.java
! src/share/classes/javax/swing/text/html/FormSubmitEvent.java
! src/share/classes/javax/swing/text/html/FormView.java
! src/share/classes/javax/swing/text/html/FrameSetView.java
! src/share/classes/javax/swing/text/html/HTML.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java
! src/share/classes/javax/swing/text/html/HTMLWriter.java
! src/share/classes/javax/swing/text/html/ImageView.java
! src/share/classes/javax/swing/text/html/InlineView.java
! src/share/classes/javax/swing/text/html/ObjectView.java
! src/share/classes/javax/swing/text/html/Option.java
! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java
! src/share/classes/javax/swing/text/html/OptionListModel.java
! src/share/classes/javax/swing/text/html/ParagraphView.java
! src/share/classes/javax/swing/text/html/StyleSheet.java
! src/share/classes/javax/swing/text/html/TableView.java
! src/share/classes/javax/swing/text/html/package.html
! src/share/classes/javax/swing/text/html/parser/ContentModel.java
! src/share/classes/javax/swing/text/html/parser/DocumentParser.java
! src/share/classes/javax/swing/text/html/parser/Element.java
! src/share/classes/javax/swing/text/html/parser/package.html
! src/share/classes/javax/swing/text/package.html
! src/share/classes/javax/swing/text/rtf/RTFReader.java
! src/share/classes/javax/swing/text/rtf/package.html
! src/share/classes/javax/swing/tree/AbstractLayoutCache.java
! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java
! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java
! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java
! src/share/classes/javax/swing/tree/DefaultTreeModel.java
! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java
! src/share/classes/javax/swing/tree/ExpandVetoException.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
! src/share/classes/javax/swing/tree/TreeCellRenderer.java
! src/share/classes/javax/swing/tree/TreeModel.java
! src/share/classes/javax/swing/tree/TreeNode.java
! src/share/classes/javax/swing/tree/TreePath.java
! src/share/classes/javax/swing/tree/TreeSelectionModel.java
! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java
! src/share/classes/javax/swing/tree/package.html
! src/share/classes/javax/swing/undo/CannotRedoException.java
! src/share/classes/javax/swing/undo/CannotUndoException.java
! src/share/classes/javax/swing/undo/UndoManager.java
! src/share/classes/javax/swing/undo/package.html
! src/share/classes/javax/xml/crypto/KeySelector.java
! src/share/classes/javax/xml/crypto/MarshalException.java
! src/share/classes/javax/xml/crypto/dsig/Manifest.java
! src/share/classes/javax/xml/crypto/dsig/TransformException.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java
! src/share/classes/jdk/internal/org/xml/sax/Attributes.java
! src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java
! src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java
! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java
! src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java
! src/share/classes/jdk/internal/org/xml/sax/InputSource.java
! src/share/classes/jdk/internal/org/xml/sax/Locator.java
! src/share/classes/jdk/internal/org/xml/sax/SAXException.java
! src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java
! src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java
! src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java
! src/share/classes/jdk/internal/org/xml/sax/XMLReader.java
! src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java
! src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java
! src/share/classes/jdk/internal/util/xml/XMLStreamException.java
! src/share/classes/jdk/internal/util/xml/impl/Parser.java
! src/share/classes/org/ietf/jgss/GSSContext.java
! src/share/classes/org/ietf/jgss/GSSCredential.java
! src/share/classes/org/ietf/jgss/GSSException.java
! src/share/classes/org/ietf/jgss/GSSManager.java
! src/share/classes/org/ietf/jgss/GSSName.java
! src/share/classes/org/ietf/jgss/package.html
! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java
! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java
! src/share/classes/sun/applet/AppletClassLoader.java
! src/share/classes/sun/applet/AppletPanel.java
! src/share/classes/sun/applet/AppletSecurity.java
! src/share/classes/sun/applet/AppletViewer.java
! src/share/classes/sun/applet/Main.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/awt/CausedFocusEvent.java
! src/share/classes/sun/awt/CharsetString.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/EventListenerAggregate.java
! src/share/classes/sun/awt/FontConfiguration.java
! src/share/classes/sun/awt/FontDescriptor.java
! src/share/classes/sun/awt/HToolkit.java
! src/share/classes/sun/awt/HeadlessToolkit.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerProvider.java
! src/share/classes/sun/awt/ModalityEvent.java
! src/share/classes/sun/awt/NativeLibLoader.java
! src/share/classes/sun/awt/NullComponentPeer.java
! src/share/classes/sun/awt/PaintEventDispatcher.java
! src/share/classes/sun/awt/PeerEvent.java
! src/share/classes/sun/awt/ScrollPaneWheelScroller.java
! src/share/classes/sun/awt/SunDisplayChanger.java
! src/share/classes/sun/awt/SunGraphicsCallback.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/UngrabEvent.java
! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java
! src/share/classes/sun/awt/datatransfer/TransferableProxy.java
! src/share/classes/sun/awt/im/CompositionArea.java
! src/share/classes/sun/awt/im/CompositionAreaHandler.java
! src/share/classes/sun/awt/im/ExecutableInputMethodManager.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/awt/im/InputMethodContext.java
! src/share/classes/sun/awt/im/InputMethodJFrame.java
! src/share/classes/sun/awt/im/InputMethodManager.java
! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java
! src/share/classes/sun/awt/image/ByteBandedRaster.java
! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/ByteInterleavedRaster.java
! src/share/classes/sun/awt/image/BytePackedRaster.java
! src/share/classes/sun/awt/image/ImageRepresentation.java
! src/share/classes/sun/awt/image/IntegerComponentRaster.java
! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java
! src/share/classes/sun/awt/image/JPEGImageDecoder.java
! src/share/classes/sun/awt/image/NativeLibLoader.java
! src/share/classes/sun/awt/image/ShortBandedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/classes/sun/awt/image/ShortInterleavedRaster.java
! src/share/classes/sun/awt/image/SurfaceManager.java
! src/share/classes/sun/awt/image/VolatileSurfaceManager.java
! src/share/classes/sun/awt/shell/ShellFolderManager.java
! src/share/classes/sun/dc/DuctusRenderingEngine.java
! src/share/classes/sun/font/CMap.java
! src/share/classes/sun/font/CreatedFontTracker.java
! src/share/classes/sun/font/ExtendedTextSourceLabel.java
! src/share/classes/sun/font/FileFont.java
! src/share/classes/sun/font/FileFontStrike.java
! src/share/classes/sun/font/FontManagerFactory.java
! src/share/classes/sun/font/FontManagerForSGE.java
! src/share/classes/sun/font/FreetypeFontScaler.java
! src/share/classes/sun/font/GlyphLayout.java
! src/share/classes/sun/font/GlyphList.java
! src/share/classes/sun/font/LayoutPathImpl.java
! src/share/classes/sun/font/StandardGlyphVector.java
! src/share/classes/sun/font/StandardTextSource.java
! src/share/classes/sun/font/StrikeCache.java
! src/share/classes/sun/font/SunFontManager.java
! src/share/classes/sun/font/TextLabelFactory.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/font/Type1Font.java
! src/share/classes/sun/instrument/InstrumentationImpl.java
! src/share/classes/sun/invoke/WrapperInstance.java
! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/invoke/util/VerifyType.java
! src/share/classes/sun/java2d/Disposer.java
! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/SurfaceDataProxy.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/PCMM.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/classes/sun/java2d/loops/Blit.java
! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java
! src/share/classes/sun/java2d/loops/MaskFill.java
! src/share/classes/sun/java2d/loops/ProcessPath.java
! src/share/classes/sun/java2d/loops/SurfaceType.java
! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java
! src/share/classes/sun/java2d/opengl/OGLDrawImage.java
! src/share/classes/sun/java2d/opengl/OGLPaints.java
! src/share/classes/sun/java2d/opengl/OGLRenderQueue.java
! src/share/classes/sun/java2d/opengl/OGLRenderer.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java
! src/share/classes/sun/java2d/pipe/AAShapePipe.java
! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java
! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java
! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/GlyphListPipe.java
! src/share/classes/sun/java2d/pipe/LoopPipe.java
! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java
! src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java
! src/share/classes/sun/java2d/pipe/Region.java
! src/share/classes/sun/java2d/pipe/RegionIterator.java
! src/share/classes/sun/java2d/pipe/RenderingEngine.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java
! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/launcher/resources/launcher_de.properties
! src/share/classes/sun/launcher/resources/launcher_es.properties
! src/share/classes/sun/launcher/resources/launcher_fr.properties
! src/share/classes/sun/launcher/resources/launcher_it.properties
! src/share/classes/sun/launcher/resources/launcher_ja.properties
! src/share/classes/sun/launcher/resources/launcher_ko.properties
! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
! src/share/classes/sun/launcher/resources/launcher_sv.properties
! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties
! src/share/classes/sun/management/Agent.java
! src/share/classes/sun/management/AgentConfigurationError.java
! src/share/classes/sun/management/BaseOperatingSystemImpl.java
! src/share/classes/sun/management/HotSpotDiagnostic.java
! src/share/classes/sun/management/RuntimeImpl.java
! src/share/classes/sun/management/counter/perf/InstrumentationException.java
! src/share/classes/sun/management/counter/perf/PerfDataType.java
! src/share/classes/sun/management/resources/agent_de.properties
! src/share/classes/sun/management/resources/agent_es.properties
! src/share/classes/sun/management/resources/agent_fr.properties
! src/share/classes/sun/management/resources/agent_it.properties
! src/share/classes/sun/management/resources/agent_ja.properties
! src/share/classes/sun/management/resources/agent_ko.properties
! src/share/classes/sun/management/resources/agent_pt_BR.properties
! src/share/classes/sun/management/resources/agent_sv.properties
! src/share/classes/sun/management/resources/agent_zh_CN.properties
! src/share/classes/sun/management/resources/agent_zh_TW.properties
! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java
! src/share/classes/sun/misc/CRC16.java
! src/share/classes/sun/misc/CharacterDecoder.java
! src/share/classes/sun/misc/ClassFileTransformer.java
! src/share/classes/sun/misc/ExtensionDependency.java
! src/share/classes/sun/misc/JavaAWTAccess.java
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/PerfCounter.java
! src/share/classes/sun/misc/PerformanceLogger.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/misc/VM.java
! src/share/classes/sun/misc/Version.java.template
! src/share/classes/sun/misc/resources/Messages_de.java
! src/share/classes/sun/misc/resources/Messages_es.java
! src/share/classes/sun/misc/resources/Messages_fr.java
! src/share/classes/sun/misc/resources/Messages_it.java
! src/share/classes/sun/misc/resources/Messages_ja.java
! src/share/classes/sun/misc/resources/Messages_ko.java
! src/share/classes/sun/misc/resources/Messages_pt_BR.java
! src/share/classes/sun/misc/resources/Messages_sv.java
! src/share/classes/sun/misc/resources/Messages_zh_CN.java
! src/share/classes/sun/misc/resources/Messages_zh_TW.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/TelnetOutputStream.java
! src/share/classes/sun/net/ftp/FtpClient.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/httpserver/ChunkedInputStream.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
! src/share/classes/sun/net/smtp/SmtpProtocolException.java
! src/share/classes/sun/net/spi/DefaultProxySelector.java
! src/share/classes/sun/net/www/MessageHeader.java
! src/share/classes/sun/net/www/content/image/gif.java
! src/share/classes/sun/net/www/content/image/jpeg.java
! src/share/classes/sun/net/www/content/image/png.java
! src/share/classes/sun/net/www/content/image/x_xbitmap.java
! src/share/classes/sun/net/www/content/image/x_xpixmap.java
! src/share/classes/sun/net/www/http/ChunkedInputStream.java
! src/share/classes/sun/net/www/http/ChunkedOutputStream.java
! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java
! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java
! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOStatus.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeDispatcher.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/ThreadPool.java
! src/share/classes/sun/nio/ch/Util.java
! src/share/classes/sun/nio/cs/UTF_8.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
! src/share/classes/sun/nio/cs/ext/HKSCS.java
! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java
! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java
! src/share/classes/sun/nio/fs/Util.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PSPrinterJob.java
! src/share/classes/sun/print/PathGraphics.java
! src/share/classes/sun/print/PrintJob2D.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/share/classes/sun/print/ServiceDialog.java
! src/share/classes/sun/reflect/AccessorGenerator.java
! src/share/classes/sun/reflect/MethodAccessorGenerator.java
! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java
! src/share/classes/sun/reflect/generics/repository/ClassRepository.java
! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
! src/share/classes/sun/reflect/misc/MethodUtil.java
! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/rmi/rmic/RemoteClass.java
! src/share/classes/sun/rmi/rmic/Util.java
! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java
! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties
! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties
! src/share/classes/sun/rmi/server/Activation.java
! src/share/classes/sun/rmi/server/MarshalInputStream.java
! src/share/classes/sun/rmi/server/resources/rmid_de.properties
! src/share/classes/sun/rmi/server/resources/rmid_es.properties
! src/share/classes/sun/rmi/server/resources/rmid_fr.properties
! src/share/classes/sun/rmi/server/resources/rmid_it.properties
! src/share/classes/sun/rmi/server/resources/rmid_ja.properties
! src/share/classes/sun/rmi/server/resources/rmid_ko.properties
! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties
! src/share/classes/sun/rmi/server/resources/rmid_sv.properties
! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties
! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties
! src/share/classes/sun/rmi/transport/ObjectTable.java
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! src/share/classes/sun/rmi/transport/proxy/WrappedSocket.java
! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java
! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java
! src/share/classes/sun/security/ec/CurveDB.java
! src/share/classes/sun/security/ec/ECDHKeyAgreement.java
! src/share/classes/sun/security/ec/ECDSASignature.java
! src/share/classes/sun/security/ec/ECKeyPairGenerator.java
! src/share/classes/sun/security/ec/ECParameters.java
! src/share/classes/sun/security/ec/ECPublicKeyImpl.java
! src/share/classes/sun/security/ec/NamedCurve.java
! src/share/classes/sun/security/ec/SunECEntries.java
! src/share/classes/sun/security/jca/GetInstance.java
! src/share/classes/sun/security/jgss/GSSCaller.java
! src/share/classes/sun/security/jgss/GSSManagerImpl.java
! src/share/classes/sun/security/jgss/HttpCaller.java
! src/share/classes/sun/security/jgss/LoginConfigImpl.java
! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java
! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java
! src/share/classes/sun/security/jgss/krb5/InitialToken.java
! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java
! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
! src/share/classes/sun/security/jgss/krb5/MessageToken.java
! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java
! src/share/classes/sun/security/jgss/krb5/SubjectComber.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java
! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/Credentials.java
! src/share/classes/sun/security/krb5/EncryptedData.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/KrbApRep.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/PrincipalName.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! src/share/classes/sun/security/krb5/internal/Krb5.java
! src/share/classes/sun/security/krb5/internal/NetClient.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! src/share/classes/sun/security/krb5/internal/rcache/AuthList.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/pkcs10/PKCS10.java
! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11KeyStore.java
! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java
! src/share/classes/sun/security/provider/DSA.java
! src/share/classes/sun/security/provider/PolicyFile.java
! src/share/classes/sun/security/provider/X509Factory.java
! src/share/classes/sun/security/provider/certpath/AdjacencyList.java
! src/share/classes/sun/security/provider/certpath/CertPathHelper.java
! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java
! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java
! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
! src/share/classes/sun/security/ssl/AppInputStream.java
! src/share/classes/sun/security/ssl/ByteBufferInputStream.java
! src/share/classes/sun/security/ssl/CipherSuiteList.java
! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHCrypt.java
! src/share/classes/sun/security/ssl/HandshakeHash.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/Krb5Helper.java
! src/share/classes/sun/security/ssl/Krb5Proxy.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/ssl/SessionId.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java
! src/share/classes/sun/security/timestamp/TSRequest.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/tools/jarsigner/Resources.java
! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java
! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/tools/policytool/Resources.java
! src/share/classes/sun/security/tools/policytool/Resources_de.java
! src/share/classes/sun/security/tools/policytool/Resources_es.java
! src/share/classes/sun/security/tools/policytool/Resources_fr.java
! src/share/classes/sun/security/tools/policytool/Resources_it.java
! src/share/classes/sun/security/tools/policytool/Resources_ja.java
! src/share/classes/sun/security/tools/policytool/Resources_ko.java
! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/policytool/Resources_sv.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java
! src/share/classes/sun/security/util/AuthResources_pt_BR.java
! src/share/classes/sun/security/util/AuthResources_zh_CN.java
! src/share/classes/sun/security/util/AuthResources_zh_TW.java
! src/share/classes/sun/security/util/DerIndefLenConverter.java
! src/share/classes/sun/security/util/ECKeySizeParameterSpec.java
! src/share/classes/sun/security/util/ECUtil.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
! src/share/classes/sun/security/util/Resources.java
! src/share/classes/sun/security/util/Resources_de.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java
! src/share/classes/sun/security/util/Resources_ja.java
! src/share/classes/sun/security/util/Resources_ko.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/security/util/Resources_sv.java
! src/share/classes/sun/security/util/Resources_zh_CN.java
! src/share/classes/sun/security/util/Resources_zh_TW.java
! src/share/classes/sun/security/util/SecurityConstants.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! src/share/classes/sun/security/x509/URIName.java
! src/share/classes/sun/swing/DefaultLayoutStyle.java
! src/share/classes/sun/swing/FilePane.java
! src/share/classes/sun/swing/PrintingStatus.java
! src/share/classes/sun/swing/SwingAccessor.java
! src/share/classes/sun/swing/SwingLazyValue.java
! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
! src/share/classes/sun/swing/text/TextComponentPrintable.java
! src/share/classes/sun/text/bidi/BidiBase.java
! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java
! src/share/classes/sun/text/normalizer/UCharacter.java
! src/share/classes/sun/text/resources/th/CollationData_th.java
! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java
! src/share/classes/sun/tools/jar/JarException.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/Manifest.java
! src/share/classes/sun/tools/jar/SignatureFile.java
! src/share/classes/sun/tools/jar/resources/jar.properties
! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties
! src/share/classes/sun/tools/java/BinaryConstantPool.java
! src/share/classes/sun/tools/java/ClassDeclaration.java
! src/share/classes/sun/tools/java/MemberDefinition.java
! src/share/classes/sun/tools/java/RuntimeConstants.java
! src/share/classes/sun/tools/jconsole/AboutDialog.java
! src/share/classes/sun/tools/jconsole/BorderedComponent.java
! src/share/classes/sun/tools/jconsole/JConsole.java
! src/share/classes/sun/tools/jconsole/ProxyClient.java
! src/share/classes/sun/tools/jconsole/SummaryTab.java
! src/share/classes/sun/tools/jconsole/ThreadTab.java
! src/share/classes/sun/tools/jconsole/inspector/Utils.java
! src/share/classes/sun/tools/jconsole/inspector/XObject.java
! src/share/classes/sun/tools/jconsole/inspector/XTextField.java
! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jps/Jps.java
! src/share/classes/sun/tools/jstack/JStack.java
! src/share/classes/sun/tools/jstat/ColumnFormat.java
! src/share/classes/sun/tools/jstat/RowClosure.java
! src/share/classes/sun/tools/jstat/resources/jstat_options
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java
! src/share/classes/sun/tools/serialver/SerialVer.java
! src/share/classes/sun/tools/tree/ExprExpression.java
! src/share/classes/sun/tools/tree/FieldExpression.java
! src/share/classes/sun/tracing/ProviderSkeleton.java
! src/share/classes/sun/tracing/dtrace/DTraceProvider.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/locale/LanguageTag.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java
! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java
! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template
! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java
! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! src/share/classes/sun/util/logging/LoggingProxy.java
! src/share/classes/sun/util/logging/LoggingSupport.java
! src/share/classes/sun/util/logging/resources/logging.properties
! src/share/classes/sun/util/logging/resources/logging_de.properties
! src/share/classes/sun/util/logging/resources/logging_es.properties
! src/share/classes/sun/util/logging/resources/logging_fr.properties
! src/share/classes/sun/util/logging/resources/logging_it.properties
! src/share/classes/sun/util/logging/resources/logging_ja.properties
! src/share/classes/sun/util/logging/resources/logging_ko.properties
! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties
! src/share/classes/sun/util/logging/resources/logging_sv.properties
! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java
! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
! src/share/demo/applets/MoleculeViewer/XYZApp.java
! src/share/demo/applets/WireFrame/ThreeD.java
! src/share/demo/java2d/J2DBench/build.xml
! src/share/demo/java2d/J2DBench/src/j2dbench/Destinations.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Group.java
! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Modifier.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Node.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java
! src/share/demo/java2d/J2DBench/src/j2dbench/ResultSet.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Test.java
! src/share/demo/java2d/J2DBench/src/j2dbench/TestEnvironment.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/IIOComparator.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/MiscTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/RenderTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputStreamTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputStreamTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextConstructionTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextMeasureTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextRenderTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/ui/CompactLayout.java
! src/share/demo/java2d/J2DBench/src/j2dbench/ui/EnableButton.java
! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java
! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java
! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java
! src/share/demo/jfc/Font2DTest/FontPanel.java
! src/share/demo/jfc/TableExample/TableExample4.java
! src/share/demo/jvmti/hprof/debug_malloc.c
! src/share/demo/jvmti/hprof/hprof_class.c
! src/share/demo/jvmti/hprof/hprof_event.c
! src/share/demo/jvmti/hprof/hprof_init.c
! src/share/demo/jvmti/hprof/hprof_md.h
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
! src/share/javavm/export/jawt.h
! src/share/lib/calendars.properties
! src/share/native/com/sun/media/sound/DirectAudioDevice.c
! src/share/native/com/sun/media/sound/Platform.c
! src/share/native/com/sun/media/sound/PlatformMidi.h
! src/share/native/com/sun/media/sound/SoundDefs.h
! src/share/native/com/sun/media/sound/Utilities.h
! src/share/native/java/lang/SecurityManager.c
! src/share/native/java/lang/System.c
! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c
! src/share/native/java/lang/java_props.h
! src/share/native/java/net/Inet4Address.c
! src/share/native/java/net/Inet6Address.c
! src/share/native/java/net/InetAddress.c
! src/share/native/java/net/net_util.c
! src/share/native/java/net/net_util.h
! src/share/native/java/util/zip/Inflater.c
! src/share/native/java/util/zip/ZipFile.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/java/util/zip/zip_util.h
! src/share/native/sun/awt/debug/debug_assert.h
! src/share/native/sun/awt/debug/debug_mem.c
! src/share/native/sun/awt/debug/debug_trace.h
! src/share/native/sun/awt/debug/debug_util.h
! src/share/native/sun/awt/image/BufImgSurfaceData.c
! src/share/native/sun/awt/image/DataBufferNative.c
! src/share/native/sun/awt/image/awt_ImageRep.c
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/image/awt_parseImage.h
! src/share/native/sun/awt/image/cvutils/img_dcm.h
! src/share/native/sun/awt/image/cvutils/img_dcm8.h
! src/share/native/sun/awt/image/cvutils/img_globals.c
! src/share/native/sun/awt/image/cvutils/img_replscale.h
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
! src/share/native/sun/awt/image/jpeg/jpegdecoder.c
! src/share/native/sun/awt/libpng/CHANGES
! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! src/share/native/sun/awt/medialib/mlib_ImageAffine.c
! src/share/native/sun/awt/medialib/mlib_ImageAffine.h
! src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c
! src/share/native/sun/awt/medialib/mlib_ImageColorTrue2Index.c
! src/share/native/sun/awt/medialib/mlib_ImageConv.h
! src/share/native/sun/awt/medialib/mlib_ImageConvMxN.c
! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_D64nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_F32nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageCopy_Bit.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c
! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h
! src/share/native/sun/awt/medialib/mlib_image.h
! src/share/native/sun/awt/medialib/mlib_sys.c
! src/share/native/sun/awt/medialib/mlib_types.h
! src/share/native/sun/awt/medialib/safe_alloc.h
! src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c
! src/share/native/sun/awt/splashscreen/splashscreen_gif.c
! src/share/native/sun/awt/splashscreen/splashscreen_impl.h
! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c
! src/share/native/sun/awt/splashscreen/splashscreen_png.c
! src/share/native/sun/font/AccelGlyphCache.c
! src/share/native/sun/font/DrawGlyphList.c
! src/share/native/sun/font/FontInstanceAdapter.cpp
! src/share/native/sun/font/FontInstanceAdapter.h
! src/share/native/sun/font/fontscalerdefs.h
! src/share/native/sun/font/freetypeScaler.c
! src/share/native/sun/font/sunFont.c
! src/share/native/sun/font/sunfontids.h
! src/share/native/sun/java2d/Disposer.c
! src/share/native/sun/java2d/SurfaceData.c
! src/share/native/sun/java2d/cmm/lcms/LCMS.c
! src/share/native/sun/java2d/loops/AnyByteBinary.h
! src/share/native/sun/java2d/loops/Blit.c
! src/share/native/sun/java2d/loops/BlitBg.c
! src/share/native/sun/java2d/loops/ByteIndexed.h
! src/share/native/sun/java2d/loops/DrawPath.c
! src/share/native/sun/java2d/loops/DrawPolygons.c
! src/share/native/sun/java2d/loops/FillPath.c
! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c
! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
! src/share/native/sun/java2d/loops/IntArgb.h
! src/share/native/sun/java2d/loops/IntArgbBm.h
! src/share/native/sun/java2d/loops/IntArgbPre.h
! src/share/native/sun/java2d/loops/MaskBlit.c
! src/share/native/sun/java2d/loops/MaskFill.c
! src/share/native/sun/java2d/loops/ProcessPath.c
! src/share/native/sun/java2d/loops/ScaledBlit.c
! src/share/native/sun/java2d/loops/TransformHelper.c
! src/share/native/sun/java2d/loops/Ushort4444Argb.h
! src/share/native/sun/java2d/loops/UshortIndexed.h
! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
! src/share/native/sun/java2d/opengl/OGLContext.c
! src/share/native/sun/java2d/opengl/OGLContext.h
! src/share/native/sun/java2d/opengl/OGLFuncs.h
! src/share/native/sun/java2d/opengl/OGLRenderQueue.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.h
! src/share/native/sun/java2d/opengl/OGLTextRenderer.c
! src/share/native/sun/java2d/opengl/OGLVertexCache.c
! src/share/native/sun/java2d/opengl/OGLVertexCache.h
! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c
! src/share/native/sun/java2d/pipe/Region.c
! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c
! src/share/native/sun/java2d/pipe/SpanClipRenderer.c
! src/share/native/sun/management/HotSpotDiagnostic.c
! src/share/native/sun/reflect/Reflection.c
! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
! src/share/native/sun/security/jgss/wrapper/NativeUtil.c
! src/share/native/sun/security/jgss/wrapper/gssapi.h
! src/share/native/sun/security/krb5/nativeccache.c
! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c
! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/share/npt/npt.h
! src/share/npt/utf.c
! src/share/sample/jmx/jmx-scandir/index.html
! src/share/sample/scripting/scriptpad/src/scripts/memory.sh
! src/share/transport/socket/socketTransport.c
! src/share/transport/socket/sysSocket.h
! src/solaris/back/linker_md.c
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/classes/java/net/DefaultInterface.java
! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/ListHelper.java
! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java
! src/solaris/classes/sun/awt/X11/XChoicePeerListener.java
! src/solaris/classes/sun/awt/X11/XClipboard.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/solaris/classes/sun/awt/X11/XDesktopPeer.java
! src/solaris/classes/sun/awt/X11/XDialogPeer.java
! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java
! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/XMSelection.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XMenuWindow.java
! src/solaris/classes/sun/awt/X11/XPanelPeer.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XRepaintArea.java
! src/solaris/classes/sun/awt/X11/XRobotPeer.java
! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XlibWrapper.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h
! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/solaris/classes/sun/awt/X11GraphicsDevice.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties
! src/solaris/classes/sun/awt/motif/X11JIS0201.java
! src/solaris/classes/sun/awt/motif/X11JIS0208.java
! src/solaris/classes/sun/awt/motif/X11JIS0212.java
! src/solaris/classes/sun/font/DelegateStrike.java
! src/solaris/classes/sun/font/FontConfigManager.java
! src/solaris/classes/sun/font/NativeStrike.java
! src/solaris/classes/sun/font/XMap.java
! src/solaris/classes/sun/font/XRGlyphCacheEntry.java
! src/solaris/classes/sun/font/XRTextRenderer.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/java2d/jules/TileTrapContainer.java
! src/solaris/classes/sun/java2d/x11/X11Renderer.java
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java
! src/solaris/classes/sun/java2d/xr/MaskTile.java
! src/solaris/classes/sun/java2d/xr/MaskTileManager.java
! src/solaris/classes/sun/java2d/xr/XRBackend.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRColor.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRDrawImage.java
! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java
! src/solaris/classes/sun/java2d/xr/XRMaskImage.java
! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/solaris/classes/sun/java2d/xr/XRPaints.java
! src/solaris/classes/sun/java2d/xr/XRRenderer.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java
! src/solaris/classes/sun/management/OperatingSystemImpl.java
! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EventPortWrapper.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/nio/ch/KQueue.java
! src/solaris/classes/sun/nio/ch/KQueuePort.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java
! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java
! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixCopyFile.java
! src/solaris/classes/sun/nio/fs/UnixException.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixMountEntry.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixUriUtils.java
! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java
! src/solaris/classes/sun/print/AttributeClass.java
! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintJob.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! src/solaris/demo/jni/Poller/Poller.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/solaris/javavm/export/jni_md.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiIn.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiOut.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h
! src/solaris/native/com/sun/security/auth/module/Solaris.c
! src/solaris/native/com/sun/security/auth/module/Unix.c
! src/solaris/native/java/lang/ProcessEnvironment_md.c
! src/solaris/native/java/lang/UNIXProcess_md.c
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/linux_close.c
! src/solaris/native/java/net/net_util_md.c
! src/solaris/native/sun/awt/CUPSfuncs.c
! src/solaris/native/sun/awt/VDrawingArea.c
! src/solaris/native/sun/awt/X11Color.c
! src/solaris/native/sun/awt/awt.h
! src/solaris/native/sun/awt/awt_AWTEvent.c
! src/solaris/native/sun/awt/awt_Component.h
! src/solaris/native/sun/awt/awt_Font.c
! src/solaris/native/sun/awt/awt_Font.h
! src/solaris/native/sun/awt/awt_LoadLibrary.c
! src/solaris/native/sun/awt/awt_Mlib.c
! src/solaris/native/sun/awt/awt_Mlib.h
! src/solaris/native/sun/awt/awt_Robot.c
! src/solaris/native/sun/awt/awt_UNIXToolkit.c
! src/solaris/native/sun/awt/awt_p.h
! src/solaris/native/sun/awt/canvas.h
! src/solaris/native/sun/awt/fontpath.c
! src/solaris/native/sun/awt/initIDs.c
! src/solaris/native/sun/awt/jawt.c
! src/solaris/native/sun/awt/multiVis.c
! src/solaris/native/sun/awt/multi_font.c
! src/solaris/native/sun/awt/multi_font.h
! src/solaris/native/sun/awt/robot_common.c
! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h
! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c
! src/solaris/native/sun/awt/swing_GTKEngine.c
! src/solaris/native/sun/font/X11FontScaler.c
! src/solaris/native/sun/font/X11TextRenderer.c
! src/solaris/native/sun/java2d/j2d_md.h
! src/solaris/native/sun/java2d/loops/mlib_ImageZoom_NN.c
! src/solaris/native/sun/java2d/loops/vis_FuncArray.c
! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h
! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h
! src/solaris/native/sun/java2d/x11/X11Renderer.c
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
! src/solaris/native/sun/java2d/x11/XRSurfaceData.c
! src/solaris/native/sun/management/LinuxOperatingSystem.c
! src/solaris/native/sun/management/MacosxOperatingSystem.c
! src/solaris/native/sun/management/OperatingSystemImpl.c
! src/solaris/native/sun/management/SolarisOperatingSystem.c
! src/solaris/native/sun/nio/ch/Net.c
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
! src/solaris/native/sun/security/smartcardio/pcsc_md.c
! src/solaris/native/sun/xawt/XToolkit.c
! src/solaris/native/sun/xawt/XWindow.c
! src/solaris/transport/socket/socket_md.c
! src/windows/back/linker_md.c
! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java
! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java
! src/windows/classes/java/lang/ProcessImpl.java
! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java
! src/windows/classes/java/net/DefaultInterface.java
! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java
! src/windows/classes/java/net/DualStackPlainSocketImpl.java
! src/windows/classes/java/net/PlainSocketImpl.java
! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java
! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java
! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java
! src/windows/classes/sun/awt/windows/WBufferStrategy.java
! src/windows/classes/sun/awt/windows/WCanvasPeer.java
! src/windows/classes/sun/awt/windows/WClipboard.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
! src/windows/classes/sun/awt/windows/WDesktopProperties.java
! src/windows/classes/sun/awt/windows/WDialogPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
! src/windows/classes/sun/awt/windows/WFramePeer.java
! src/windows/classes/sun/awt/windows/WInputMethod.java
! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java
! src/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java
! src/windows/classes/sun/awt/windows/WPageDialog.java
! src/windows/classes/sun/awt/windows/WPageDialogPeer.java
! src/windows/classes/sun/awt/windows/WPathGraphics.java
! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialog.java
! src/windows/classes/sun/awt/windows/WPrinterJob.java
! src/windows/classes/sun/awt/windows/WRobotPeer.java
! src/windows/classes/sun/awt/windows/WScrollPanePeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/classes/sun/awt/windows/fontconfig.properties
! src/windows/classes/sun/java2d/ScreenUpdateManager.java
! src/windows/classes/sun/java2d/d3d/D3DRenderer.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/windows/classes/sun/java2d/windows/GDIRenderer.java
! src/windows/classes/sun/management/OperatingSystemImpl.java
! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java
! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/windows/classes/sun/nio/ch/DatagramDispatcher.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
! src/windows/classes/sun/nio/ch/FileKey.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/PipeImpl.java
! src/windows/classes/sun/nio/ch/PollArrayWrapper.java
! src/windows/classes/sun/nio/ch/SocketDispatcher.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/fs/WindowsConstants.java
! src/windows/classes/sun/nio/fs/WindowsFileCopy.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/classes/sun/nio/fs/WindowsPath.java
! src/windows/classes/sun/nio/fs/WindowsSecurity.java
! src/windows/classes/sun/nio/fs/WindowsWatchService.java
! src/windows/classes/sun/print/Win32MediaTray.java
! src/windows/classes/sun/print/Win32PrintJob.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java
! src/windows/demo/jvmti/hprof/hprof_md.c
! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp
! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c
! src/windows/native/java/io/Console_md.c
! src/windows/native/java/lang/ProcessImpl_md.c
! src/windows/native/java/lang/java_props_md.c
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/DualStackPlainSocketImpl.c
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h
! src/windows/native/java/net/SocketInputStream.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/icmp.h
! src/windows/native/java/net/net_util_md.c
! src/windows/native/java/net/net_util_md.h
! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
! src/windows/native/sun/font/fontpath.c
! src/windows/native/sun/font/lcdglyph.c
! src/windows/native/sun/java2d/d3d/D3DBadHardware.h
! src/windows/native/sun/java2d/d3d/D3DPipeline.h
! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp
! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h
! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp
! src/windows/native/sun/java2d/windows/GDIRenderer.cpp
! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp
! src/windows/native/sun/management/OperatingSystemImpl.c
! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c
! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c
! src/windows/native/sun/nio/ch/Net.c
! src/windows/native/sun/nio/ch/SocketChannelImpl.c
! src/windows/native/sun/nio/ch/SocketDispatcher.c
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c
! src/windows/native/sun/security/krb5/NativeCreds.c
! src/windows/native/sun/windows/CmdIDList.cpp
! src/windows/native/sun/windows/Devices.cpp
! src/windows/native/sun/windows/Devices.h
! src/windows/native/sun/windows/DllUtil.cpp
! src/windows/native/sun/windows/DllUtil.h
! src/windows/native/sun/windows/ObjectList.cpp
! src/windows/native/sun/windows/ObjectList.h
! src/windows/native/sun/windows/ShellFolder2.cpp
! src/windows/native/sun/windows/ThemeReader.cpp
! src/windows/native/sun/windows/WPrinterJob.cpp
! src/windows/native/sun/windows/alloc.h
! src/windows/native/sun/windows/awt.h
! src/windows/native/sun/windows/awt_BitmapUtil.cpp
! src/windows/native/sun/windows/awt_Button.cpp
! src/windows/native/sun/windows/awt_Checkbox.cpp
! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Choice.h
! src/windows/native/sun/windows/awt_Clipboard.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_DataTransferer.cpp
! src/windows/native/sun/windows/awt_Debug.cpp
! src/windows/native/sun/windows/awt_Debug.h
! src/windows/native/sun/windows/awt_DesktopProperties.cpp
! src/windows/native/sun/windows/awt_Dialog.h
! src/windows/native/sun/windows/awt_DnDDT.cpp
! src/windows/native/sun/windows/awt_Font.h
! src/windows/native/sun/windows/awt_Frame.h
! src/windows/native/sun/windows/awt_InputMethod.cpp
! src/windows/native/sun/windows/awt_InputTextInfor.cpp
! src/windows/native/sun/windows/awt_List.h
! src/windows/native/sun/windows/awt_Menu.cpp
! src/windows/native/sun/windows/awt_Menu.h
! src/windows/native/sun/windows/awt_MenuBar.cpp
! src/windows/native/sun/windows/awt_MenuBar.h
! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_MenuItem.h
! src/windows/native/sun/windows/awt_Mlib.cpp
! src/windows/native/sun/windows/awt_Mlib.h
! src/windows/native/sun/windows/awt_Object.cpp
! src/windows/native/sun/windows/awt_Object.h
! src/windows/native/sun/windows/awt_PopupMenu.cpp
! src/windows/native/sun/windows/awt_PopupMenu.h
! src/windows/native/sun/windows/awt_PrintControl.h
! src/windows/native/sun/windows/awt_PrintJob.cpp
! src/windows/native/sun/windows/awt_Robot.cpp
! src/windows/native/sun/windows/awt_Robot.h
! src/windows/native/sun/windows/awt_ScrollPane.cpp
! src/windows/native/sun/windows/awt_TextArea.cpp
! src/windows/native/sun/windows/awt_TextArea.h
! src/windows/native/sun/windows/awt_TextComponent.cpp
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_TextField.cpp
! src/windows/native/sun/windows/awt_TextField.h
! src/windows/native/sun/windows/awt_Toolkit.h
! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp
! src/windows/native/sun/windows/awt_Window.h
! src/windows/native/sun/windows/awt_ole.cpp
! src/windows/native/sun/windows/awtmsg.h
! src/windows/native/sun/windows/stdhdrs.h
! src/windows/transport/socket/socket_md.c
! test/com/oracle/net/sanity.sh
! test/com/sun/jdi/ExceptionEvents.java
! test/com/sun/jdi/FilterNoMatch.java
! test/com/sun/jdi/JDIScaffold.java
! test/com/sun/jdi/MethodEntryExitEvents.java
! test/com/sun/jdi/MethodExitReturnValuesTest.java
! test/com/sun/jdi/NativeInstanceFilter.java
! test/com/sun/jdi/NoLaunchOptionTest.java
! test/com/sun/jdi/RepStep.java
! test/com/sun/jdi/TestScaffold.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java
! test/com/sun/jndi/cosnaming/CNNameParser.java
! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java
! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java
! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh
! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh
! test/com/sun/net/httpserver/Test9a.java
! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java
! test/com/sun/tools/attach/Application.java
! test/com/sun/tools/attach/RedefineAgent.java
! test/com/sun/tools/extcheck/TestExtcheckArgs.sh
! test/demo/jvmti/mtrace/TraceJFrame.java
! test/demo/zipfs/ZipFSTester.java
! test/demo/zipfs/basic.sh
! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java
! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html
! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html
! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html
! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html
! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java
! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html
! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java
! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html
! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html
! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java
! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html
! test/java/awt/FileDialog/MultipleMode/MultipleMode.html
! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html
! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java
! test/java/awt/Focus/6981400/Test1.java
! test/java/awt/Focus/6981400/Test2.java
! test/java/awt/Focus/6981400/Test3.java
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java
! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html
! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java
! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html
! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html
! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java
! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html
! test/java/awt/FontMetrics/StyledSpaceAdvance.java
! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java
! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html
! test/java/awt/Frame/ShownOnPack/ShownOnPack.html
! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java
! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java
! test/java/awt/Graphics/LineClipTest.java
! test/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java
! test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java
! test/java/awt/GraphicsDevice/CloneConfigsTest.java
! test/java/awt/JAWT/Makefile.cygwin
! test/java/awt/JAWT/Makefile.unix
! test/java/awt/JAWT/Makefile.win
! test/java/awt/JAWT/MyCanvas.java
! test/java/awt/JAWT/myfile.c
! test/java/awt/JAWT/myfile.cpp
! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java
! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java
! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html
! test/java/awt/List/SetFontTest/SetFontTest.html
! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java
! test/java/awt/Menu/OpensWithNoGrab/OpensWithNoGrab.java
! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java
! test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java
! test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java
! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html
! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html
! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java
! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html
! test/java/awt/PrintJob/Text/stringwidth.sh
! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java
! test/java/awt/Robot/ManualInstructions/ManualInstructions.java
! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java
! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java
! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java
! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html
! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java
! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html
! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java
! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java
! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java
! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java
! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java
! test/java/awt/Window/Grab/GrabTest.java
! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java
! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java
! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java
! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html
! test/java/awt/dnd/Button2DragTest/Button2DragTest.html
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java
! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html
! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html
! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java
! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java
! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html
! test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java
! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java
! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html
! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java
! test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java
! test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java
! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html
! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html
! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java
! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java
! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html
! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html
! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java
! test/java/awt/im/4490692/bug4490692.html
! test/java/awt/im/4959409/bug4959409.html
! test/java/awt/im/JTextFieldTest.html
! test/java/awt/image/BufferedImage/TinyScale.java
! test/java/awt/image/GetSamplesTest.java
! test/java/awt/image/IncorrectSampleMaskTest.java
! test/java/awt/image/mlib/MlibOpsTest.java
! test/java/awt/print/PageFormat/PageFormatFromAttributes.java
! test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java
! test/java/awt/print/PrinterJob/Collate2DPrintingTest.java
! test/java/awt/print/PrinterJob/PrintGlyphVectorTest.java
! test/java/awt/regtesthelpers/Util.java
! test/java/beans/Beans/6669869/TestDesignTime.java
! test/java/beans/Beans/6669869/TestGuiAvailable.java
! test/java/beans/EventHandler/Test6277266.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
! test/java/beans/Introspector/6380849/beans/FirstBean.java
! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java
! test/java/beans/Introspector/6380849/beans/SecondBean.java
! test/java/beans/Introspector/6380849/beans/ThirdBean.java
! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java
! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java
! test/java/beans/Introspector/6976577/test/Accessor.java
! test/java/beans/Introspector/7122138/pack/Sub.java
! test/java/beans/Introspector/7122138/pack/Super.java
! test/java/beans/Introspector/Test4683761.java
! test/java/beans/Introspector/Test6660539.java
! test/java/beans/Performance/Test7122740.java
! test/java/beans/Performance/Test7184799.java
! test/java/beans/XMLEncoder/6380849/Bean.java
! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java
! test/java/beans/XMLEncoder/AbstractTest.java
! test/java/beans/XMLEncoder/BeanValidator.java
! test/java/beans/XMLEncoder/Test4631471.java
! test/java/beans/XMLEncoder/Test4679556.java
! test/java/beans/XMLEncoder/java_awt_BorderLayout.java
! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java
! test/java/io/File/GetXSpace.sh
! test/java/io/FileInputStream/OpsAfterClose.java
! test/java/io/FileOutputStream/OpsAfterClose.java
! test/java/io/RandomAccessFile/OpsAfterClose.java
! test/java/io/Serializable/class/run.sh
! test/java/io/Serializable/evolution/AddedExternField/run.sh
! test/java/io/Serializable/evolution/RenamePackage/run.sh
! test/java/io/Serializable/maskSyntheticModifier/run.sh
! test/java/io/Serializable/packageAccess/run.sh
! test/java/io/Serializable/resolveClass/consTest/run.sh
! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java
! test/java/io/Serializable/resolveClass/deserializeButton/Test.java
! test/java/io/Serializable/resolveClass/deserializeButton/run.sh
! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java
! test/java/io/Serializable/subclass/run.sh
! test/java/io/Serializable/superclassDataLoss/run.sh
! test/java/io/Serializable/unnamedPackageSwitch/run.sh
! test/java/lang/CharSequence/DefaultTest.java
! test/java/lang/Class/forName/NonJavaNames.sh
! test/java/lang/Class/getEnclosingClass/build.sh
! test/java/lang/ClassLoader/Assert.sh
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
! test/java/lang/ClassLoader/getdotresource.sh
! test/java/lang/Double/ParseDouble.java
! test/java/lang/Float/ParseFloat.java
! test/java/lang/IntegralPrimitiveToString.java
! test/java/lang/Math/CubeRootTests.java
! test/java/lang/Math/ExactArithTests.java
! test/java/lang/Math/Expm1Tests.java
! test/java/lang/Math/HyperbolicTests.java
! test/java/lang/Math/Log10Tests.java
! test/java/lang/Math/Log1pTests.java
! test/java/lang/Math/Tests.java
! test/java/lang/PrimitiveSumMinMaxTest.java
! test/java/lang/String/Split.java
! test/java/lang/String/ToLowerCase.java
! test/java/lang/StringBuffer/BufferForwarding.java
! test/java/lang/StringBuffer/TestSynchronization.java
! test/java/lang/StringBuilder/BuilderForwarding.java
! test/java/lang/StringBuilder/Supplementary.java
! test/java/lang/System/MacEncoding/ExpectedEncoding.java
! test/java/lang/Thread/GenerifyStackTraces.java
! test/java/lang/Thread/ThreadStateTest.java
! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java
! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh
! test/java/lang/instrument/ManifestTest.sh
! test/java/lang/instrument/ParallelTransformerLoader.sh
! test/java/lang/instrument/RedefineClassWithNativeMethod.sh
! test/java/lang/instrument/RedefineMethodAddInvoke.sh
! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh
! test/java/lang/invoke/AccessControlTest.java
! test/java/lang/invoke/BigArityTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeDynamicPrintArgs.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/PrivateInvokeTest.java
! test/java/lang/invoke/RicochetTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java
! test/java/lang/invoke/lambda/LUtils.java
! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlTest.java
! test/java/lang/invoke/remote/RemoteExample.java
! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java
! test/java/lang/management/CompilationMXBean/Basic.java
! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java
! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
! test/java/lang/management/MemoryMXBean/MemoryTest.java
! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
! test/java/lang/management/RuntimeMXBean/UpTime.java
! test/java/lang/management/ThreadMXBean/LockedMonitors.java
! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java
! test/java/lang/management/ThreadMXBean/Locks.java
! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java
! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java
! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java
! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java
! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java
! test/java/lang/ref/ReferenceEnqueuePending.java
! test/java/lang/reflect/Array/ExceedMaxDim.java
! test/java/lang/reflect/Generics/Probe.java
! test/java/lang/reflect/Method/IsDefaultTest.java
! test/java/lang/reflect/Proxy/Basic1.java
! test/java/lang/reflect/Proxy/ClassRestrictions.java
! test/java/math/BigDecimal/CompareToTests.java
! test/java/math/BigDecimal/FloatDoubleValueTests.java
! test/java/math/BigDecimal/IntegralDivisionTests.java
! test/java/math/BigDecimal/StrippingZerosTest.java
! test/java/math/BigInteger/CompareToTests.java
! test/java/math/BigInteger/DivisionOverflow.java
! test/java/math/BigInteger/ExtremeShiftingTests.java
! test/java/net/Authenticator/B4933582.sh
! test/java/net/BindException/Test.java
! test/java/net/CookieHandler/CookieManagerTest.java
! test/java/net/CookieHandler/TestHttpCookie.java
! test/java/net/Inet6Address/serialize/Serialize.java
! test/java/net/InterfaceAddress/NetworkPrefixLength.java
! test/java/net/MulticastSocket/TestInterfaces.java
! test/java/net/NetworkInterface/Equals.java
! test/java/net/NetworkInterface/IndexTest.java
! test/java/net/NetworkInterface/Test.java
! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh
! test/java/net/Socket/LingerTest.java
! test/java/net/Socks/SocksProxyVersion.java
! test/java/net/URI/Test.java
! test/java/net/URL/HandlerLoop.java
! test/java/net/URL/Test.java
! test/java/net/URL/URIToURLTest.java
! test/java/net/URLClassLoader/closetest/CloseTest.java
! test/java/net/URLClassLoader/closetest/Common.java
! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java
! test/java/net/URLClassLoader/getresourceasstream/test.sh
! test/java/net/URLConnection/RequestPropertyValues.java
! test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
! test/java/net/URLPermission/nstest/SimpleNameService.java
! test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java
! test/java/net/ipv6tests/B6521014.java
! test/java/net/ipv6tests/BadIPv6Addresses.java
! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java
! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh
! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java
! test/java/nio/channels/DatagramChannel/Connect.java
! test/java/nio/channels/DatagramChannel/ConnectedSend.java
! test/java/nio/channels/DatagramChannel/SendToUnresolved.java
! test/java/nio/channels/Pipe/PipeInterrupt.java
! test/java/nio/channels/Selector/LotsOfChannels.java
! test/java/nio/channels/Selector/SelectorLimit.java
! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
! test/java/nio/channels/SocketChannel/ShortWrite.java
! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh
! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java
! test/java/nio/file/Files/CheckPermissions.java
! test/java/nio/file/Files/delete_on_close.sh
! test/java/nio/file/Files/walkFileTree/CreateFileTree.java
! test/java/nio/file/Files/walkFileTree/MaxDepth.java
! test/java/nio/file/Files/walkFileTree/SkipSiblings.java
! test/java/nio/file/Files/walkFileTree/TerminateWalk.java
! test/java/nio/file/Files/walkFileTree/find.sh
! test/java/nio/file/WatchService/SensitivityModifier.java
! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java
! test/java/nio/file/attribute/FileTime/Basic.java
! test/java/rmi/MarshalledObject/compare/Compare.java
! test/java/rmi/MarshalledObject/compare/HashCode.java
! test/java/rmi/MarshalledObject/compare/NullReference.java
! test/java/rmi/Naming/DefaultRegistryPort.java
! test/java/rmi/Naming/LookupIPv6.java
! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java
! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java
! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java
! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java
! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java
! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java
! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java
! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java
! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh
! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java
! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java
! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java
! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java
! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java
! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java
! test/java/rmi/activation/Activatable/restartService/RestartService.java
! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java
! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java
! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java
! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java
! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java
! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java
! test/java/rmi/activation/CommandEnvironment/NullOptions.java
! test/java/rmi/activation/log/LogTest.java
! test/java/rmi/dgc/VMID/CheckVMID.java
! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java
! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java
! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java
! test/java/rmi/invalidName/InvalidName.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java
! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java
! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java
! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java
! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java
! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
! test/java/rmi/server/RMIClassLoader/spi/Installed.java
! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java
! test/java/rmi/server/RMIClassLoader/spi/Property.java
! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java
! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java
! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java
! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java
! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java
! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java
! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java
! test/java/rmi/server/Unmarshal/PrimitiveClasses.java
! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java
! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java
! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java
! test/java/rmi/server/clientStackTrace/ClientStackTrace.java
! test/java/rmi/server/getRemoteClass/GetRemoteClass.java
! test/java/rmi/server/serverStackTrace/ServerStackTrace.java
! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java
! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java
! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java
! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java
! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
! test/java/security/Principal/Implies.java
! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/signedfirst/Dyn.sh
! test/java/security/Security/signedfirst/Static.sh
! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh
! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java
! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh
! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh
! test/java/security/cert/CertStore/NoLDAP.java
! test/java/security/cert/CertificateFactory/slowstream.sh
! test/java/security/cert/CertificateRevokedException/Basic.java
! test/java/security/cert/pkix/policyChanges/TestPolicy.java
! test/java/text/Bidi/BidiConformance.java
! test/java/text/Format/DecimalFormat/TieRoundingTest.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/java/time/test/java/util/TestFormatter.java
! test/java/util/Arrays/ParallelSorting.java
! test/java/util/Base64/TestBase64.java
! test/java/util/Base64/TestBase64Golden.java
! test/java/util/Calendar/GenericTimeZoneNamesTest.sh
! test/java/util/Calendar/NarrowNamesTest.sh
! test/java/util/Collection/CollectionDefaults.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collection/testlibrary/CollectionAsserts.java
! test/java/util/Collection/testlibrary/CollectionSupplier.java
! test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java
! test/java/util/Collection/testlibrary/ExtendsAbstractList.java
! test/java/util/Collection/testlibrary/ExtendsAbstractSet.java
! test/java/util/Collections/CheckedIdentityMap.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/ReverseOrder.java
! test/java/util/Formatter/Basic-X.java.template
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/Basic.sh
! test/java/util/Formatter/BasicBigDecimal.java
! test/java/util/Formatter/BasicDouble.java
! test/java/util/Formatter/BasicDoubleObject.java
! test/java/util/Formatter/BasicFloat.java
! test/java/util/Formatter/BasicFloatObject.java
! test/java/util/Iterator/IteratorDefaults.java
! test/java/util/LinkedHashMap/Basic.java
! test/java/util/List/ListDefaults.java
! test/java/util/Locale/InternationalBAT.java
! test/java/util/Locale/LocaleEnhanceTest.java
! test/java/util/Locale/LocaleTestFmwk.java
! test/java/util/Locale/tools/EquivMapsGenerator.java
! test/java/util/Map/BasicSerialization.java
! test/java/util/Map/Collisions.java
! test/java/util/Map/EntryComparators.java
! test/java/util/Map/LockStep.java
! test/java/util/NavigableMap/LockStep.java
! test/java/util/PluggableLocale/BreakIteratorProviderTest.java
! test/java/util/PluggableLocale/CollatorProviderTest.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/DateFormatProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.java
! test/java/util/PluggableLocale/NumberFormatProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PriorityQueue/RemoveContains.java
! test/java/util/ResourceBundle/Bug6299235Test.sh
! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh
! test/java/util/ResourceBundle/ResourceBundleTest.java
! test/java/util/ServiceLoader/basic.sh
! test/java/util/TimeZone/Bug6912560.java
! test/java/util/TimeZone/CLDRDisplayNamesTest.java
! test/java/util/TimeZone/ListTimeZones.java
! test/java/util/TimeZone/OldIDMappingTest.java
! test/java/util/TimeZone/OldIDMappingTest.sh
! test/java/util/TimeZone/TzIDOldMapping.java
! test/java/util/TreeMap/Clone.java
! test/java/util/concurrent/Executors/PrivilegedCallables.java
! test/java/util/concurrent/FutureTask/Throw.java
! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
! test/java/util/concurrent/atomic/AtomicReferenceTest.java
! test/java/util/concurrent/locks/Lock/FlakyMutex.java
! test/java/util/function/BinaryOperator/BasicTest.java
! test/java/util/jar/TestExtra.java
! test/java/util/logging/CheckLockLocationTest.java
! test/java/util/logging/LoggerSupplierAPIsTest.java
! test/java/util/logging/ParentLoggersTest.java
! test/java/util/logging/Reflect.java
! test/java/util/prefs/AddNodeChangeListener.java
! test/java/util/prefs/CheckUserPrefFirst.java
! test/java/util/prefs/CheckUserPrefLater.java
! test/java/util/prefs/CommentsInXml.java
! test/java/util/prefs/ConflictInFlush.java
! test/java/util/prefs/ExportNode.java
! test/java/util/prefs/ExportSubtree.java
! test/java/util/prefs/RemoveReadOnlyNode.java
! test/java/util/prefs/RemoveUnregedListener.java
! test/java/util/regex/POSIX_Unicode.java
! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java
! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
! test/java/util/stream/bootlib/java/util/stream/TestData.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java
! test/java/util/zip/3GBZipFiles.sh
! test/java/util/zip/LargeZip.java
! test/java/util/zip/StoredCRC.java
! test/java/util/zip/TotalInOut.java
! test/java/util/zip/ZipFile/Assortment.java
! test/java/util/zip/ZipFile/FinalizeZipFile.java
! test/javax/crypto/SecretKeyFactory/FailOverTest.sh
! test/javax/imageio/plugins/gif/GIFPassListenerTest.java
! test/javax/imageio/plugins/gif/GifTransparencyTest.java
! test/javax/management/MBeanInfo/SerializationTest1.java
! test/javax/management/modelmbean/LoggingExceptionTest.java
! test/javax/management/monitor/CounterMonitorThresholdTest.java
! test/javax/management/monitor/NullAttributeValueTest.java
! test/javax/management/remote/mandatory/connection/AddressableTest.java
! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java
! test/javax/management/remote/mandatory/connection/CloseableTest.java
! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java
! test/javax/management/remote/mandatory/connection/ConnectionTest.java
! test/javax/management/remote/mandatory/connection/IIOPURLTest.java
! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java
! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java
! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java
! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java
! test/javax/management/remote/mandatory/loading/MissingClassTest.java
! test/javax/management/remote/mandatory/notif/DeadListenerTest.java
! test/javax/management/remote/mandatory/provider/ProviderTest.java
! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java
! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java
! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java
! test/javax/print/DialogMargins.java
! test/javax/print/StreamPrintingOrientation.java
! test/javax/print/applet/AppletPrintLookup.html
! test/javax/print/attribute/autosense/PrintAutoSenseData.java
! test/javax/rmi/ssl/SocketFactoryTest.java
! test/javax/script/CauseExceptionTest.java
! test/javax/script/ExceptionTest.java
! test/javax/script/GetInterfaceTest.java
! test/javax/script/Helper.java
! test/javax/script/ProviderTest.sh
! test/javax/script/StringWriterPrintTest.java
! test/javax/script/Test5.java
! test/javax/script/Test6.java
! test/javax/script/UnescapedBracketRegExTest.java
! test/javax/script/VersionTest.java
! test/javax/security/auth/kerberos/KerberosTixDateTest.java
! test/javax/sound/midi/File/SMPTESequence.java
! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java
! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java
! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java
! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java
! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java
! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java
! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java
! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java
! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java
! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java
! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java
! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java
! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java
! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java
! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java
! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java
! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java
! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java
! test/javax/sound/midi/Gervill/SoftChannel/Controller.java
! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java
! test/javax/sound/midi/Gervill/SoftChannel/Mono.java
! test/javax/sound/midi/Gervill/SoftChannel/Mute.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java
! test/javax/sound/midi/Gervill/SoftChannel/Omni.java
! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java
! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java
! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java
! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java
! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java
! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java
! test/javax/sound/midi/Gervill/SoftChannel/Solo.java
! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java
! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java
! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java
! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java
! test/javax/sound/midi/Gervill/SoftReceiver/Close.java
! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java
! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java
! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java
! test/javax/sound/midi/Gervill/SoftTuning/GetName.java
! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java
! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java
! test/javax/sound/midi/Gervill/SoftTuning/Load1.java
! test/javax/sound/midi/Gervill/SoftTuning/Load2.java
! test/javax/sound/midi/Gervill/SoftTuning/Load4.java
! test/javax/sound/midi/Gervill/SoftTuning/Load5.java
! test/javax/sound/midi/Gervill/SoftTuning/Load6.java
! test/javax/sound/midi/Gervill/SoftTuning/Load7.java
! test/javax/sound/midi/Gervill/SoftTuning/Load8.java
! test/javax/sound/midi/Gervill/SoftTuning/Load9.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java
! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java
! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java
! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java
! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java
! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java
! test/javax/sound/sampled/Clip/ClipSetPos.java
! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java
! test/javax/sound/sampled/DirectAudio/bug6400879.java
! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java
! test/javax/sound/sampled/FileWriter/WriterCloseInput.java
! test/javax/swing/JCheckBox/4449413/bug4449413.html
! test/javax/swing/JColorChooser/Test4222508.html
! test/javax/swing/JColorChooser/Test4759306.html
! test/javax/swing/JColorChooser/Test4759934.html
! test/javax/swing/JColorChooser/Test4887836.html
! test/javax/swing/JColorChooser/Test6348456.html
! test/javax/swing/JColorChooser/Test6977726.html
! test/javax/swing/JComboBox/7082443/bug7082443.java
! test/javax/swing/JComponent/4337267/bug4337267.java
! test/javax/swing/JComponent/6683775/bug6683775.java
! test/javax/swing/JEditorPane/4492274/test.html
! test/javax/swing/JEditorPane/6917744/test.html
! test/javax/swing/JEditorPane/bug4714674.java
! test/javax/swing/JFileChooser/6570445/bug6570445.java
! test/javax/swing/JFileChooser/6698013/bug6698013.html
! test/javax/swing/JFileChooser/6698013/bug6698013.java
! test/javax/swing/JFileChooser/6798062/bug6798062.html
! test/javax/swing/JInternalFrame/6726866/bug6726866.html
! test/javax/swing/JInternalFrame/6726866/bug6726866.java
! test/javax/swing/JList/6462008/bug6462008.java
! test/javax/swing/JPopupMenu/4966112/bug4966112.java
! test/javax/swing/JPopupMenu/6694823/bug6694823.java
! test/javax/swing/JSlider/4987336/bug4987336.html
! test/javax/swing/JSlider/6524424/bug6524424.html
! test/javax/swing/JSlider/6587742/bug6587742.html
! test/javax/swing/JSlider/6742358/bug6742358.html
! test/javax/swing/JSplitPane/4885629/bug4885629.java
! test/javax/swing/JTabbedPane/4310381/bug4310381.html
! test/javax/swing/JTable/6788484/bug6788484.java
! test/javax/swing/JTable/8005019/bug8005019.java
! test/javax/swing/JTextArea/7049024/bug7049024.java
! test/javax/swing/JTree/4314199/bug4314199.html
! test/javax/swing/JTree/4908142/bug4908142.java
! test/javax/swing/JTree/6263446/bug6263446.java
! test/javax/swing/SpringLayout/4726194/bug4726194.java
! test/javax/swing/SwingUtilities/7170657/bug7170657.java
! test/javax/swing/border/Test4129681.html
! test/javax/swing/border/Test4243289.html
! test/javax/swing/border/Test4247606.html
! test/javax/swing/border/Test4252164.html
! test/javax/swing/border/Test4760089.html
! test/javax/swing/border/Test6910490.html
! test/javax/swing/border/Test7022041.java
! test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java
! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java
! test/javax/swing/text/html/TableView/7030332/bug7030332.html
! test/javax/swing/text/html/parser/Parser/7003777/bug7003777.java
! test/jdk/lambda/ArrayCtorRefTest.java
! test/jdk/lambda/FDTest.java
! test/jdk/lambda/LambdaTranslationCompoundSamTest.java
! test/jdk/lambda/LambdaTranslationInInterface.java
! test/jdk/lambda/LambdaTranslationTest1.java
! test/jdk/lambda/LambdaTranslationTest2.java
! test/jdk/lambda/MethodReferenceTestInnerDefault.java
! test/jdk/lambda/MethodReferenceTestInnerInstance.java
! test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java
! test/jdk/lambda/MethodReferenceTestInstance.java
! test/jdk/lambda/MethodReferenceTestInstanceMethod.java
! test/jdk/lambda/MethodReferenceTestKinds.java
! test/jdk/lambda/MethodReferenceTestNew.java
! test/jdk/lambda/MethodReferenceTestNewInner.java
! test/jdk/lambda/MethodReferenceTestSuper.java
! test/jdk/lambda/MethodReferenceTestSuperDefault.java
! test/jdk/lambda/MethodReferenceTestTypeConversion.java
! test/jdk/lambda/MethodReferenceTestVarArgs.java
! test/jdk/lambda/MethodReferenceTestVarArgsExt.java
! test/jdk/lambda/MethodReferenceTestVarArgsSuper.java
! test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java
! test/jdk/lambda/MethodReferenceTestVarArgsThis.java
! test/jdk/lambda/TestInnerCtorRef.java
! test/jdk/lambda/TestPrivateCtorRef.java
! test/jdk/lambda/separate/AttributeInjector.java
! test/jdk/lambda/separate/ClassFile.java
! test/jdk/lambda/separate/ClassFilePreprocessor.java
! test/jdk/lambda/separate/ClassToInterfaceConverter.java
! test/jdk/lambda/separate/Compiler.java
! test/jdk/lambda/separate/DirectedClassLoader.java
! test/jdk/lambda/separate/SourceModel.java
! test/jdk/lambda/separate/TestHarness.java
! test/jdk/lambda/shapegen/ClassCase.java
! test/jdk/lambda/shapegen/Hierarchy.java
! test/jdk/lambda/shapegen/HierarchyGenerator.java
! test/jdk/lambda/shapegen/Rule.java
! test/jdk/lambda/shapegen/RuleGroup.java
! test/jdk/lambda/shapegen/TTNode.java
! test/jdk/lambda/shapegen/TTParser.java
! test/jdk/lambda/shapegen/TTShape.java
! test/jdk/lambda/vm/DefaultMethodRegressionTests.java
! test/jdk/lambda/vm/InterfaceAccessFlagsTest.java
! test/jdk/lambda/vm/StrictfpDefault.java
! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/invoke/util/ValueConversionsTest.java
! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java
! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvTest.java
! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html
! test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java
! test/sun/java2d/cmm/ColorConvertOp/MTColConvTest.java
! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java
! test/sun/java2d/cmm/ProfileOp/SetDataTest.java
! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java
! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh
! test/sun/jvmstat/testlibrary/JavaProcess.java
! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java
! test/sun/management/jdp/ClientConnection.java
! test/sun/management/jdp/JdpTestUtil.java
! test/sun/management/jdp/JdpTestUtilTest.java
! test/sun/management/jdp/JdpUnitTest.java
! test/sun/management/jdp/PacketTest.java
! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java
! test/sun/misc/Cleaner/ExitOnThrow.java
! test/sun/misc/FloatingDecimal/OldFDBigIntForTest.java
! test/sun/misc/JavaLangAccess/NewUnsafeString.java
! test/sun/net/ftp/MarkResetTest.java
! test/sun/net/ftp/MarkResetTest.sh
! test/sun/net/sdp/sanity.sh
! test/sun/net/www/http/HttpClient/ProxyTest.java
! test/sun/net/www/http/HttpClient/RetryPost.sh
! test/sun/net/www/protocol/file/DirPermissionDenied.sh
! test/sun/net/www/protocol/http/B6299712.java
! test/sun/net/www/protocol/http/ProxyTunnelServer.java
! test/sun/net/www/protocol/http/StackTraceTest.java
! test/sun/nio/cs/EUC_TW_OLD.java
! test/sun/nio/cs/TestIBMBugs.java
! test/sun/nio/cs/TestStringCoding.java
! test/sun/nio/cs/X11CNS11643.java
! test/sun/nio/cs/X11CNS11643P1.java
! test/sun/nio/cs/X11CNS11643P2.java
! test/sun/nio/cs/X11CNS11643P3.java
! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java
! test/sun/rmi/log/ReliableLog/SnapshotSize.java
! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java
! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh
! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh
! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java
! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java
! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java
! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
! test/sun/security/krb5/MicroTime.java
! test/sun/security/krb5/ParseCAPaths.java
! test/sun/security/krb5/ServiceCredsCombination.java
! test/sun/security/krb5/auto/AcceptPermissions.java
! test/sun/security/krb5/auto/AcceptorSubKey.java
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/CleanState.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/CrossRealm.java
! test/sun/security/krb5/auto/DiffNameSameKey.java
! test/sun/security/krb5/auto/DupEtypes.java
! test/sun/security/krb5/auto/DynamicKeytab.java
! test/sun/security/krb5/auto/GSSUnbound.java
! test/sun/security/krb5/auto/HttpNegotiateServer.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/KeyTabCompat.java
! test/sun/security/krb5/auto/MoreKvno.java
! test/sun/security/krb5/auto/OneKDC.java
! test/sun/security/krb5/auto/ReplayCacheTest.java
! test/sun/security/krb5/auto/SaslUnbound.java
! test/sun/security/krb5/auto/TwoOrThree.java
! test/sun/security/krb5/auto/UnboundService.java
! test/sun/security/krb5/ccache/EmptyCC.java
! test/sun/security/krb5/config/dns.sh
! test/sun/security/krb5/etype/WeakCrypto.java
! test/sun/security/krb5/runNameEquals.sh
! test/sun/security/krb5/tools/ktcheck.sh
! test/sun/security/pkcs11/SecmodTest.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/provider/PolicyFile/Comparator.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java
! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java
! test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/tools/jarsigner/checkusage.sh
! test/sun/security/tools/jarsigner/concise_jarsigner.sh
! test/sun/security/tools/jarsigner/crl.sh
! test/sun/security/tools/jarsigner/emptymanifest.sh
! test/sun/security/tools/jarsigner/newsize7.sh
! test/sun/security/tools/jarsigner/onlymanifest.sh
! test/sun/security/tools/jarsigner/passtype.sh
! test/sun/security/tools/jarsigner/samename.sh
! test/sun/security/tools/jarsigner/ts.sh
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/CloseFile.java
! test/sun/security/tools/keytool/DummyProvider.java
! test/sun/security/tools/keytool/ListKeychainStore.sh
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/tools/keytool/UnknownAndUnparseable.java
! test/sun/security/tools/keytool/console.sh
! test/sun/security/tools/keytool/emptysubject.sh
! test/sun/security/tools/keytool/importreadall.sh
! test/sun/security/tools/keytool/printssl.sh
! test/sun/security/tools/keytool/readjar.sh
! test/sun/security/tools/keytool/selfissued.sh
! test/sun/security/tools/keytool/standard.sh
! test/sun/security/tools/keytool/trystore.sh
! test/sun/security/tools/policytool/Alias.sh
! test/sun/security/tools/policytool/ChangeUI.sh
! test/sun/security/tools/policytool/OpenPolicy.sh
! test/sun/security/tools/policytool/SaveAs.sh
! test/sun/security/tools/policytool/UpdatePermissions.sh
! test/sun/security/tools/policytool/UsePolicy.sh
! test/sun/security/tools/policytool/i18n.sh
! test/sun/security/validator/certreplace.sh
! test/sun/security/validator/samedn.sh
! test/sun/security/x509/X509CRLImpl/Verify.java
! test/sun/security/x509/X509CertImpl/Verify.java
! test/sun/tools/jps/jps-V_2.sh
! test/sun/tools/jrunscript/CheckEngine.java
! test/sun/util/calendar/zi/BackEnd.java
! test/sun/util/calendar/zi/Checksum.java
! test/sun/util/calendar/zi/DayOfWeek.java
! test/sun/util/calendar/zi/Gen.java
! test/sun/util/calendar/zi/GenDoc.java
! test/sun/util/calendar/zi/Main.java
! test/sun/util/calendar/zi/Mappings.java
! test/sun/util/calendar/zi/Month.java
! test/sun/util/calendar/zi/Rule.java
! test/sun/util/calendar/zi/RuleDay.java
! test/sun/util/calendar/zi/RuleRec.java
! test/sun/util/calendar/zi/Simple.java
! test/sun/util/calendar/zi/TestZoneInfo310.java
! test/sun/util/calendar/zi/Time.java
! test/sun/util/calendar/zi/Timezone.java
! test/sun/util/calendar/zi/TzIDOldMapping.java
! test/sun/util/calendar/zi/Zone.java
! test/sun/util/calendar/zi/ZoneInfoFile.java
! test/sun/util/calendar/zi/ZoneInfoOld.java
! test/sun/util/calendar/zi/ZoneRec.java
! test/sun/util/calendar/zi/Zoneinfo.java
! test/sun/util/calendar/zi/tzdata/gmt
! test/sun/util/calendar/zi/tzdata/jdk11_backward
! test/sun/util/calendar/zi/tzdata_jdk/gmt
! test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward
! test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward
! test/sun/util/resources/Locale/Bug6275682.java
! test/sun/util/resources/TimeZone/Bug6317929.java
! test/tools/jar/ChangeDir.java
! test/tools/jar/JarEntryTime.java
! test/tools/pack200/NoBeans.java
! test/tools/pack200/Reflect.java

Changeset: e1499442453b
Author:    lana
Date:      2013-12-26 22:39 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e1499442453b

Merge

! src/share/classes/javax/swing/text/AbstractDocument.java

Changeset: 7e10ee00fe41
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7e10ee00fe41

Added tag jdk8-b122 for changeset e1499442453b

! .hgtags


From john.coomes at oracle.com  Fri Jan  3 12:49:44 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:49:44 +0000
Subject: hg: hsx/hotspot-main/langtools: 12 new changesets
Message-ID: <20140103205034.40AD862374@hg.openjdk.java.net>

Changeset: 2d0a0ae7fa9c
Author:    ksrini
Date:      2013-12-06 09:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2d0a0ae7fa9c

8029504: Regression: TestDocRootLink test fails on Windows
Reviewed-by: bpatel, jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java

Changeset: 5bf0af735c61
Author:    vromero
Date:      2013-12-09 19:29 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5bf0af735c61

8029569: internal javac cast exception when resolving varargs ambiguity
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/T8029569/VarargsAmbiguityCrashTest.java
+ test/tools/javac/T8029569/VarargsAmbiguityCrashTest.out

Changeset: 847cc0cccfa1
Author:    rfield
Date:      2013-12-11 11:56 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/847cc0cccfa1

8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses
Summary: properly type convert the body of a lambda expression
Reviewed-by: vromero

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/LambdaParenGeneric.java
+ test/tools/javac/lambda/LambdaParenGenericOrig.java

Changeset: d80c3d6f4f05
Author:    lana
Date:      2013-12-12 19:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d80c3d6f4f05

Merge


Changeset: 8832b6048e65
Author:    vromero
Date:      2013-12-13 14:13 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8832b6048e65

8029721: javac crash for annotated parameter type of lambda in a field
Reviewed-by: rfield, jfranck

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java
! test/tools/javac/lambda/LambdaScope05.out

Changeset: 6d1f9d1fd585
Author:    darcy
Date:      2013-12-17 10:26 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6d1f9d1fd585

8030080: Correct misstatement in JSR 269 MR (in javax.lang.model)
Reviewed-by: jfranck

! src/share/classes/javax/lang/model/type/IntersectionType.java
! src/share/classes/javax/lang/model/util/Types.java

Changeset: f1be939b49f6
Author:    mfang
Date:      2013-12-17 23:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f1be939b49f6

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties
! src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties

Changeset: b8ebde062692
Author:    bpatel
Date:      2013-12-18 19:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b8ebde062692

8016549: jdk7 javadocs are hard to read
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! test/com/sun/javadoc/AccessH1/AccessH1.java
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java
! test/tools/javadoc/api/basic/APITest.java

Changeset: 56943b19c119
Author:    lana
Date:      2013-12-23 14:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/56943b19c119

Merge

- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif

Changeset: 998b10c43157
Author:    ksrini
Date:      2013-12-24 09:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/998b10c43157

8029230: Update copyright year to match last edit in jdk8 langtools repository for 2013
Reviewed-by: ksrini
Contributed-by: steve.sides at oracle.com

! make/Makefile
! src/share/classes/com/sun/javadoc/AnnotationDesc.java
! src/share/classes/com/sun/source/doctree/package-info.java
! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java
! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java
! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java
! src/share/classes/com/sun/tools/jdeps/Archive.java
! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java
! src/share/classes/com/sun/tools/sjavac/CleanProperties.java
! src/share/classes/com/sun/tools/sjavac/CompileChunk.java
! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java
! src/share/classes/com/sun/tools/sjavac/CompileProperties.java
! src/share/classes/com/sun/tools/sjavac/CopyFile.java
! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/Log.java
! src/share/classes/com/sun/tools/sjavac/Module.java
! src/share/classes/com/sun/tools/sjavac/Package.java
! src/share/classes/com/sun/tools/sjavac/ProblemException.java
! src/share/classes/com/sun/tools/sjavac/Source.java
! src/share/classes/com/sun/tools/sjavac/Transformer.java
! src/share/classes/com/sun/tools/sjavac/Util.java
! src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java
! src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java
! src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java
! src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java
! src/share/classes/com/sun/tools/sjavac/server/PortFile.java
! src/share/classes/com/sun/tools/sjavac/server/SysInfo.java
! src/share/classes/javax/lang/model/element/TypeElement.java
! src/share/classes/javax/lang/model/element/VariableElement.java
! src/share/classes/javax/lang/model/element/package-info.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java
! test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java
! test/com/sun/javadoc/testAbstractMethod/pkg/A.java
! test/com/sun/javadoc/testAbstractMethod/pkg/B.java
! test/com/sun/javadoc/testAbstractMethod/pkg/C.java
! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
! test/com/sun/javadoc/testDocRootLink/pkg1/C1.java
! test/com/sun/javadoc/testDocRootLink/pkg2/C2.java
! test/com/sun/javadoc/testLegacyTaglet/C.java
! test/com/sun/javadoc/testNavigation/pkg/A.java
! test/com/sun/javadoc/testNavigation/pkg/C.java
! test/com/sun/javadoc/testNavigation/pkg/E.java
! test/com/sun/javadoc/testNavigation/pkg/I.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java
! test/tools/javac/T6725036.java
! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java
! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java
! test/tools/javac/annotations/typeAnnotations/TargetTypes.java
! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java
! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java
! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java
! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java
! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java
! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java
! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java
! test/tools/javac/cast/intersection/model/Model01.java
! test/tools/javac/cast/intersection/model/ModelChecker.java
! test/tools/javac/defaultMethods/static/Static01.java
! test/tools/javac/defaultMethods/static/Static02.java
! test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java
! test/tools/javac/defaultMethods/static/import/StaticImport1.java
! test/tools/javac/defaultMethods/static/import/StaticImport2.java
! test/tools/javac/defaultMethods/static/import/StaticImport3.java
! test/tools/javac/defaultMethods/static/import/pkg/A.java
! test/tools/javac/defaultMethods/static/import/pkg/B.java
! test/tools/javac/defaultMethods/static/import/pkg/C.java
! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
! test/tools/javac/diags/MessageFile.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java
! test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
! test/tools/javac/diags/examples/NotInProfile.java
! test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java
! test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java
! test/tools/javac/diags/examples/WhereIntersection.java
! test/tools/javac/generics/odersky/BadTest4.java
! test/tools/javac/lambda/DoubleStaticImport.java
! test/tools/javac/lambda/Intersection01.java
! test/tools/javac/lambda/Intersection02.java
! test/tools/javac/lambda/LambdaCapture06.java
! test/tools/javac/lambda/LambdaConv01.java
! test/tools/javac/lambda/LambdaExpr15.java
! test/tools/javac/lambda/MethodReference25.java
! test/tools/javac/lambda/MethodReference26.java
! test/tools/javac/lambda/MethodReference59.java
! test/tools/javac/lambda/MethodReference60.java
! test/tools/javac/lambda/TargetType51.java
! test/tools/javac/lambda/lambdaExecution/InInterface.java
! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java
! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java
! test/tools/javac/lambda/methodReference/BridgeMethod.java
! test/tools/javac/lambda/methodReference/SamConversion.java
! test/tools/javac/lambda/methodReference/SamConversionComboTest.java
! test/tools/javac/lambda/typeInference/InferenceTest2b.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/multicatch/Pos05.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java
! test/tools/javac/resolve/Pos.java
! test/tools/javac/resolve/ResolveHarness.java
! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java
! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java
! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java
! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/p/Foo.java

Changeset: 232b9cf6303a
Author:    lana
Date:      2013-12-25 10:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/232b9cf6303a

Merge


Changeset: a345cf28faca
Author:    katleman
Date:      2014-01-03 11:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a345cf28faca

Added tag jdk8-b122 for changeset 232b9cf6303a

! .hgtags


From john.coomes at oracle.com  Fri Jan  3 12:50:52 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Jan 2014 20:50:52 +0000
Subject: hg: hsx/hotspot-main/nashorn: 8 new changesets
Message-ID: <20140103205104.B7D0A62375@hg.openjdk.java.net>

Changeset: 752554d45a07
Author:    sundar
Date:      2013-12-09 09:48 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/752554d45a07

8029612: the typeErrorThrower field in ScriptFunctionImpl cannot be static and common to all Globals
Reviewed-by: attila, hannesw

! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeStrictArguments.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java

Changeset: 739f3abdfa55
Author:    sundar
Date:      2013-12-09 09:53 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/739f3abdfa55

Merge


Changeset: 4706897b4dec
Author:    attila
Date:      2013-12-09 10:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4706897b4dec

8029467: Widening of booleans causes bad results
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-8029467.js
+ test/script/basic/JDK-8029467.js.EXPECTED

Changeset: 18edd7a1b166
Author:    lagergren
Date:      2013-12-11 18:09 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/18edd7a1b166

8029780: "ant externals" broke our test harness with the latest version of the octane benchmarks
Reviewed-by: attila, sundar

! make/build-benchmark.xml
! test/script/basic/compile-octane-splitter.js.EXPECTED
! test/script/basic/compile-octane.js.EXPECTED
! test/script/basic/run-octane.js

Changeset: e452a3797290
Author:    sundar
Date:      2013-12-12 09:18 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e452a3797290

Merge


Changeset: 0225a7ca37ab
Author:    lana
Date:      2013-12-12 19:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0225a7ca37ab

Merge


Changeset: 9d112a0e7df7
Author:    lana
Date:      2013-12-23 14:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9d112a0e7df7

Merge


Changeset: 688f4167f921
Author:    katleman
Date:      2014-01-03 11:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/688f4167f921

Added tag jdk8-b122 for changeset 9d112a0e7df7

! .hgtags


From vladimir.kozlov at oracle.com  Mon Jan  6 10:04:47 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 06 Jan 2014 10:04:47 -0800
Subject: RFR(XS): 8031188: Fix for 8029015: PPC64 (part 216): opto: trap
	based null and range checks
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8A4D2@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8A4D2@DEWDFEMB12A.global.corp.sap>
Message-ID: <52CAF03F.6050503@oracle.com>

Looks good.

Vladimir

On 1/6/14 2:14 AM, Lindenmaier, Goetz wrote:
> A happy new year everybody!
>
> Could you please review and test this tiny fix?
>
> It?s in code so far only used by ppc64.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8031188-nc/
>
> fixup_flow can add new blocks with a branch instruction. Doing
> so after a trap based check added the branch behind the wrong
> Proj node. The branch would jump to the proper target, but build_oop_map
> analyses a wrong control flow.
>
> Fix: Swap the Projs in the block list so that the new block is added behind
> the proper node.
>
> Thanks  & best regards,
>
>    Goetz
>

From goetz.lindenmaier at sap.com  Mon Jan  6 02:14:50 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 6 Jan 2014 10:14:50 +0000
Subject: RFR(XS): 8031188: Fix for 8029015: PPC64 (part 216): opto: trap
	based null and range checks
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8A4D2@DEWDFEMB12A.global.corp.sap>

A happy new year everybody!

Could you please review and test this tiny fix?
It's in code so far only used by ppc64.
http://cr.openjdk.java.net/~goetz/webrevs/8031188-nc/

fixup_flow can add new blocks with a branch instruction. Doing
so after a trap based check added the branch behind the wrong
Proj node. The branch would jump to the proper target, but build_oop_map
analyses a wrong control flow.

Fix: Swap the Projs in the block list so that the new block is added behind
the proper node.

Thanks  & best regards,
  Goetz

From serguei.spitsyn at oracle.com  Mon Jan  6 11:47:08 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 06 Jan 2014 11:47:08 -0800
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C716E3.1000105@oracle.com>
References: <52C5A105.6030804@oracle.com>
	<52C6FCE2.8000906@oracle.com>	<52C708BD.9090401@oracle.com>
	<52C7119D.9020601@oracle.com> <52C716E3.1000105@oracle.com>
Message-ID: <52CB083C.5010607@oracle.com>

On 1/3/14 12:00 PM, Coleen Phillmore wrote:
>
> On 1/3/2014 2:38 PM, Jon Masamitsu wrote:
>>
>> On 1/3/2014 11:00 AM, Coleen Phillmore wrote:
>>>
>>> Jon,  Thanks for reviewing this.
>>>
>>> On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
>>>> Coleen,
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>>>>
>>>>
>>>> 146   bool contains(const void* ptr) { return bottom() < ptr && ptr 
>>>> <= _top; }
>>>>
>>>> I think bottom() points to the first chunk.  Also _top points to 
>>>> the start
>>>> of the unallocated space (next place where a chunk will be allocated).
>>>> So I would think this should be
>>>>
>>>> bool contains(const void* ptr) { return bottom() <=ptr && ptr < 
>>>> _top; }
>>>>
>>>>
>>>
>>> Yes, I agree.
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>>>>
>>>>
>>>> Don't you need some locking to protect the "chunks_in_use()" lists?
>>>>
>>>> 2382 bool SpaceManager::contains(const void *ptr) {
>>>> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
>>>> next_chunk_index(i))
>>>> 2384   {
>>>> 2385     Metachunk* curr = chunks_in_use(i);
>>>> 2386     while (curr != NULL) {
>>>> 2387       if (curr->contains(ptr)) return true;
>>>> 2388       curr = curr->next();
>>>> 2389     }
>>>> 2390   }
>>>> 2391   return false;
>>>> 2392 }
>>>> 2393
>>>
>>> If new chunks are added while this is iterating over them, they are 
>>> added to the front of the list.  This is ok because we would only 
>>> call this for metadata that is already allocated in one of the 
>>> chunks.   I don't want to add a lock but I do need some memory 
>>> ordering instructions.   I'll move the one that I had on virtual 
>>> space lists to where we add the chunks.
>>
>> Ok.  Do you think it is worth code in set_chunks_in_use() that checks
>> that the list head is set after the new chunk has been added?
>>
>> Something like
>>
>> set_chunks_in_use(new_chunk)
>> if (chunks_in_use() != NULL)
>>     assert(new_chunk->next == chunks_in_use(), "Always add new chunk 
>> to list first");
>> }
>
> I think the OrderAccess::storestore() should accomplish this. 
> chunks_in_use() shouldn't be null after this though except for at 
> deletion time.   So this code seems overly paranoid about the C++ 
> compiler not doing the stores.  Actually the C++ compiler could keep 
> all of this in a register and we'd never see things in the right order.
>
> Here's a new version with the OrderAccess::storestore();   I reran the 
> parallel class loading tests on this.
>
> http://cr.openjdk.java.net/~coleenp/8029178_2/ 
> <http://cr.openjdk.java.net/%7Ecoleenp/8029178_2/>

This looks good to me.

Thanks,
Serguei

>
> Thanks,
> Coleen
>>
>> Just a thought.
>>
>> Jon
>>
>>
>>
>>>
>>> The Metaspace/SpaceManager destructors can only be called for the 
>>> _unloading list, which is created at a safepoint and we don't walk 
>>> those lists in CLDG::contains.
>>>
>>> Thank you for pointing these out.   I'll retest and send out another 
>>> webrev.
>>>
>>> Coleen
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>>>>> Summary: Metaspace::contains cannot look at purged metaspaces 
>>>>> while CMS concurrently deallocates them.
>>>>>
>>>>> Removed 2 calls to is_metaspace_object where the object may be in 
>>>>> a deallocated metaspace.  Removed walking virtual space lists for 
>>>>> determining contains because the virtual space list can change 
>>>>> concurrently with the walk. CLDG::contains is slower but no 
>>>>> slowdowns with testing were observed.
>>>>>
>>>>> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
>>>>> parallel class loading tests and 
>>>>> nsk/coverage/arguments/arguments008 (ie. calls 
>>>>> Method::is_valid_method)
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>
>>>
>>
>


From alejandro.murillo at oracle.com  Mon Jan  6 11:53:13 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Mon, 06 Jan 2014 12:53:13 -0700
Subject: [jdk9] Heads up: Hotspot version string output is changing to
	match that of the JDK
In-Reply-To: <CAPYFHW0ZgR5+KWPFUcDqaehh+roDh=Zm4rnCFhkKpM28t3Vr2A@mail.gmail.com>
References: <52BDC689.8090009@oracle.com>
	<CAPYFHW0ZgR5+KWPFUcDqaehh+roDh=Zm4rnCFhkKpM28t3Vr2A@mail.gmail.com>
Message-ID: <52CB09A9.9060901@oracle.com>


apologies for the late reply, was out last week.
the changes going into a specific release are (and were) defined by the
purpose of that release.

Substantial changes are usually added into feature releases as they have
longer development (hence testing) cycle. Non feature releases, are done 
more
frequently and usually include mostly bug fixes

hope that answers your question
Alejandro

On 12/27/2013 1:24 PM, Jeremy Manson wrote:
> A policy question: Does this mean that we can no longer expect large 
> Hotspot changes in a single JDK release?  JDK7 has seen 
> HS21->22->23->24; some of those leaps were pretty substantial.
>
> Jeremy
>
>
> On Fri, Dec 27, 2013 at 10:27 AM, Alejandro E Murillo 
> <alejandro.murillo at oracle.com <mailto:alejandro.murillo at oracle.com>> 
> wrote:
>
>
>     There is no longer a separate hotspot version in jdk9 (see
>     attached email for details),
>     so the version string produced by java -version and java
>     -Xinternalversion in jdk9 builds
>     will be changed to match that of the JDK (as was the case before
>     Hotspot express).
>     And also to add additional info for non promoted or developers builds.
>
>     The details of this change are described here:
>
>     https://bugs.openjdk.java.net/browse/JDK-8030011
>
>     a webrev with the fix will be sent soon.
>     Let me know if you have any feedback/suggestion
>
>     thanks
>
>     -- 
>     Alejandro
>
>

-- 
Alejandro


From jon.masamitsu at oracle.com  Mon Jan  6 11:48:23 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 06 Jan 2014 11:48:23 -0800
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52C716E3.1000105@oracle.com>
References: <52C5A105.6030804@oracle.com> <52C6FCE2.8000906@oracle.com>
	<52C708BD.9090401@oracle.com> <52C7119D.9020601@oracle.com>
	<52C716E3.1000105@oracle.com>
Message-ID: <52CB0887.3090903@oracle.com>

Looks good.

Jon

On 01/03/2014 12:00 PM, Coleen Phillmore wrote:
>
> On 1/3/2014 2:38 PM, Jon Masamitsu wrote:
>>
>> On 1/3/2014 11:00 AM, Coleen Phillmore wrote:
>>>
>>> Jon,  Thanks for reviewing this.
>>>
>>> On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
>>>> Coleen,
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>>>>
>>>>
>>>> 146   bool contains(const void* ptr) { return bottom() < ptr && ptr 
>>>> <= _top; }
>>>>
>>>> I think bottom() points to the first chunk.  Also _top points to 
>>>> the start
>>>> of the unallocated space (next place where a chunk will be allocated).
>>>> So I would think this should be
>>>>
>>>> bool contains(const void* ptr) { return bottom() <=ptr && ptr < 
>>>> _top; }
>>>>
>>>>
>>>
>>> Yes, I agree.
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>>>>
>>>>
>>>> Don't you need some locking to protect the "chunks_in_use()" lists?
>>>>
>>>> 2382 bool SpaceManager::contains(const void *ptr) {
>>>> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
>>>> next_chunk_index(i))
>>>> 2384   {
>>>> 2385     Metachunk* curr = chunks_in_use(i);
>>>> 2386     while (curr != NULL) {
>>>> 2387       if (curr->contains(ptr)) return true;
>>>> 2388       curr = curr->next();
>>>> 2389     }
>>>> 2390   }
>>>> 2391   return false;
>>>> 2392 }
>>>> 2393
>>>
>>> If new chunks are added while this is iterating over them, they are 
>>> added to the front of the list.  This is ok because we would only 
>>> call this for metadata that is already allocated in one of the 
>>> chunks.   I don't want to add a lock but I do need some memory 
>>> ordering instructions.   I'll move the one that I had on virtual 
>>> space lists to where we add the chunks.
>>
>> Ok.  Do you think it is worth code in set_chunks_in_use() that checks
>> that the list head is set after the new chunk has been added?
>>
>> Something like
>>
>> set_chunks_in_use(new_chunk)
>> if (chunks_in_use() != NULL)
>>     assert(new_chunk->next == chunks_in_use(), "Always add new chunk 
>> to list first");
>> }
>
> I think the OrderAccess::storestore() should accomplish this. 
> chunks_in_use() shouldn't be null after this though except for at 
> deletion time.   So this code seems overly paranoid about the C++ 
> compiler not doing the stores.  Actually the C++ compiler could keep 
> all of this in a register and we'd never see things in the right order.
>
> Here's a new version with the OrderAccess::storestore();   I reran the 
> parallel class loading tests on this.
>
> http://cr.openjdk.java.net/~coleenp/8029178_2/ 
> <http://cr.openjdk.java.net/%7Ecoleenp/8029178_2/>
>
> Thanks,
> Coleen
>>
>> Just a thought.
>>
>> Jon
>>
>>
>>
>>>
>>> The Metaspace/SpaceManager destructors can only be called for the 
>>> _unloading list, which is created at a safepoint and we don't walk 
>>> those lists in CLDG::contains.
>>>
>>> Thank you for pointing these out.   I'll retest and send out another 
>>> webrev.
>>>
>>> Coleen
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>>>>> Summary: Metaspace::contains cannot look at purged metaspaces 
>>>>> while CMS concurrently deallocates them.
>>>>>
>>>>> Removed 2 calls to is_metaspace_object where the object may be in 
>>>>> a deallocated metaspace.  Removed walking virtual space lists for 
>>>>> determining contains because the virtual space list can change 
>>>>> concurrently with the walk. CLDG::contains is slower but no 
>>>>> slowdowns with testing were observed.
>>>>>
>>>>> Tested by SQE testbase tests, jtreg tests.   Functional testing by 
>>>>> parallel class loading tests and 
>>>>> nsk/coverage/arguments/arguments008 (ie. calls 
>>>>> Method::is_valid_method)
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>
>>>
>>
>


From alejandro.murillo at oracle.com  Mon Jan  6 12:38:12 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Mon, 06 Jan 2014 20:38:12 +0000
Subject: hg: hsx/jdk7u/hotspot: 8031061: new hotspot build - hs24.60-b07
Message-ID: <20140106203817.3A8A0623EE@hg.openjdk.java.net>

Changeset: 3cc7ee9d8bf4
Author:    amurillo
Date:      2014-01-06 11:13 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/3cc7ee9d8bf4

8031061: new hotspot build - hs24.60-b07
Reviewed-by: jcoomes

! make/hotspot_version


From Harry.Leitzell at grainger.com  Fri Jan  3 13:40:06 2014
From: Harry.Leitzell at grainger.com (Leitzell, Harry)
Date: Fri, 3 Jan 2014 21:40:06 +0000
Subject: JDK-6584008 (jvmtiStringPrimitiveCallback should not be invoked
	when string value is null) in 1.7.0_45
Message-ID: <CEEC8A55.82A3%harry.leitzell@grainger.com>

I believe I've run into this bug's race condition while using Dynatrace's
JVMTI profiling: https://bugs.openjdk.java.net/browse/JDK-6584008

I don't have time to write a patch right now that I think would be
accepted but I can if desired.


**SNIP**

#  SIGSEGV (0xb) at pc=0x00002ad23bcf3d2b, pid=2934, tid=1090189632
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
1.7.0_45-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x708d2b]  invoke_string_value_callback(int (*)(long,
long, long*, unsigned short const*, int, void*), CallbackWrapper*,
oopDesc*, void*)+0x11b


**SNIP**

---------------  T H R E A D  ---------------
Current thread (0x00002aaab02d5000):  VMThread [stack:
0x0000000040eaf000,0x0000000040fb0000] [id=2966]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
si_addr=0x000000000000000c


**SNIP**

Register to memory mapping:
RAX=0x000000000000000c is an unknown value
RBX=0x000000062789c4a0 is an oop
java.lang.String 
 - klass: 'java/lang/String'
RCX=0x0000000000000000 is an unknown value
RDX=0x000000062789c4a0 is an oop
java.lang.String 
 - klass: 'java/lang/String'
RSP=0x0000000040faecc0 is an unknown value
RBP=0x0000000040faecc0 is an unknown value
RSI=0x00002ad23c418e58: <offset 0xe2de58> in
/local/jdk1.7.0_45/jre/lib/amd64/server/libjvm.so at 0x00002ad23b5eb000
RDI=0x00002ad23c41a550: <offset 0xe2f550> in
/local/jdk1.7.0_45/jre/lib/amd64/server/libjvm.so at 0x00002ad23b5eb000
R8 =0x0000000000000000 is an unknown value
R9 =0x0000000040faecd0 is an unknown value
R10=0x0000000045c63650 is pointing into the stack for thread:
0x00002aae38027000
R11=0x00002aaaab71c9ea: <offset 0x599ea> in
/local/dynatrace/agent/downloads/5.5.0.5562/native/linux-x86-64/libdtagentc
ore.so at 0x00002aaaab6c3000
R12=0x0000000045c63130 is pointing into the stack for thread:
0x00002aae38027000
R13=0x00002ad23c418e58: <offset 0xe2de58> in
/local/jdk1.7.0_45/jre/lib/amd64/server/libjvm.so at 0x00002ad23b5eb000
R14=0x0000000040faecd0 is an unknown value
R15=0x0000000000000000 is an unknown value


Stack: [0x0000000040eaf000,0x0000000040fb0000],  sp=0x0000000040faecc0,
free space=1023k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x708d2b]  invoke_string_value_callback(int (*)(long, long,
long*, unsigned short const*, int, void*), CallbackWrapper*, oopDesc*,
void*)+0x11b
V  [libjvm.so+0x70a9d6]
IterateThroughHeapObjectClosure::do_object(oopDesc*)+0x476
V  [libjvm.so+0x8c8dca]  ContiguousSpace::object_iterate_from(WaterMark,
ObjectClosure*)+0x7a
V  [libjvm.so+0x5628bb]
GenCollectedHeap::object_iterate(ObjectClosure*)+0x3b
V  [libjvm.so+0x70b8e3]  VM_HeapIterateOperation::doit()+0x43
V  [libjvm.so+0x99b955]  VM_Operation::evaluate()+0x55
V  [libjvm.so+0x999d8a]  VMThread::evaluate_operation(VM_Operation*)+0xba
V  [libjvm.so+0x99a10e]  VMThread::loop()+0x1ce
V  [libjvm.so+0x99a580]  VMThread::run()+0x70
V  [libjvm.so+0x815288]  java_start(Thread*)+0x108

VM_Operation (0x0000000045c63170): HeapIterateOperation, mode: safepoint,
requested by thread 0x00002aae38027000



Cheers,
Harry

Harry Leitzell | Principal Performance Engineer, eCommerce | W.W.
Grainger, Inc. 
500 W Madison St, Suite 3300 | Chicago, IL 60661-4512 | +1 (312) 802-7400





From serguei.spitsyn at oracle.com  Mon Jan  6 14:30:43 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 06 Jan 2014 14:30:43 -0800
Subject: JDK-6584008 (jvmtiStringPrimitiveCallback should not be invoked
	when string value is null) in 1.7.0_45
In-Reply-To: <CEEC8A55.82A3%harry.leitzell@grainger.com>
References: <CEEC8A55.82A3%harry.leitzell@grainger.com>
Message-ID: <52CB2E93.2040504@oracle.com>

Hi Harry,

Thank you a lot for reporting this crash as it is quite helpful!

I've updated the bug report description with your information:
   https://bugs.openjdk.java.net/browse/JDK-6584008


Thanks,
Serguei


On 1/3/14 1:40 PM, Leitzell, Harry wrote:
> I believe I've run into this bug's race condition while using Dynatrace's
> JVMTI profiling: https://bugs.openjdk.java.net/browse/JDK-6584008
>
> I don't have time to write a patch right now that I think would be
> accepted but I can if desired.
>
>
> **SNIP**
>
> #  SIGSEGV (0xb) at pc=0x00002ad23bcf3d2b, pid=2934, tid=1090189632
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> 1.7.0_45-b18)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x708d2b]  invoke_string_value_callback(int (*)(long,
> long, long*, unsigned short const*, int, void*), CallbackWrapper*,
> oopDesc*, void*)+0x11b
>
>
> **SNIP**
>
> ---------------  T H R E A D  ---------------
> Current thread (0x00002aaab02d5000):  VMThread [stack:
> 0x0000000040eaf000,0x0000000040fb0000] [id=2966]
> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
> si_addr=0x000000000000000c
>
>
> **SNIP**
>
> Register to memory mapping:
> RAX=0x000000000000000c is an unknown value
> RBX=0x000000062789c4a0 is an oop
> java.lang.String
>   - klass: 'java/lang/String'
> RCX=0x0000000000000000 is an unknown value
> RDX=0x000000062789c4a0 is an oop
> java.lang.String
>   - klass: 'java/lang/String'
> RSP=0x0000000040faecc0 is an unknown value
> RBP=0x0000000040faecc0 is an unknown value
> RSI=0x00002ad23c418e58: <offset 0xe2de58> in
> /local/jdk1.7.0_45/jre/lib/amd64/server/libjvm.so at 0x00002ad23b5eb000
> RDI=0x00002ad23c41a550: <offset 0xe2f550> in
> /local/jdk1.7.0_45/jre/lib/amd64/server/libjvm.so at 0x00002ad23b5eb000
> R8 =0x0000000000000000 is an unknown value
> R9 =0x0000000040faecd0 is an unknown value
> R10=0x0000000045c63650 is pointing into the stack for thread:
> 0x00002aae38027000
> R11=0x00002aaaab71c9ea: <offset 0x599ea> in
> /local/dynatrace/agent/downloads/5.5.0.5562/native/linux-x86-64/libdtagentc
> ore.so at 0x00002aaaab6c3000
> R12=0x0000000045c63130 is pointing into the stack for thread:
> 0x00002aae38027000
> R13=0x00002ad23c418e58: <offset 0xe2de58> in
> /local/jdk1.7.0_45/jre/lib/amd64/server/libjvm.so at 0x00002ad23b5eb000
> R14=0x0000000040faecd0 is an unknown value
> R15=0x0000000000000000 is an unknown value
>
>
> Stack: [0x0000000040eaf000,0x0000000040fb0000],  sp=0x0000000040faecc0,
> free space=1023k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0x708d2b]  invoke_string_value_callback(int (*)(long, long,
> long*, unsigned short const*, int, void*), CallbackWrapper*, oopDesc*,
> void*)+0x11b
> V  [libjvm.so+0x70a9d6]
> IterateThroughHeapObjectClosure::do_object(oopDesc*)+0x476
> V  [libjvm.so+0x8c8dca]  ContiguousSpace::object_iterate_from(WaterMark,
> ObjectClosure*)+0x7a
> V  [libjvm.so+0x5628bb]
> GenCollectedHeap::object_iterate(ObjectClosure*)+0x3b
> V  [libjvm.so+0x70b8e3]  VM_HeapIterateOperation::doit()+0x43
> V  [libjvm.so+0x99b955]  VM_Operation::evaluate()+0x55
> V  [libjvm.so+0x999d8a]  VMThread::evaluate_operation(VM_Operation*)+0xba
> V  [libjvm.so+0x99a10e]  VMThread::loop()+0x1ce
> V  [libjvm.so+0x99a580]  VMThread::run()+0x70
> V  [libjvm.so+0x815288]  java_start(Thread*)+0x108
>
> VM_Operation (0x0000000045c63170): HeapIterateOperation, mode: safepoint,
> requested by thread 0x00002aae38027000
>
>
>
> Cheers,
> Harry
>
> Harry Leitzell | Principal Performance Engineer, eCommerce | W.W.
> Grainger, Inc.
> 500 W Madison St, Suite 3300 | Chicago, IL 60661-4512 | +1 (312) 802-7400
>
>
>
>


From christian.thalinger at oracle.com  Mon Jan  6 14:57:11 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 6 Jan 2014 14:57:11 -0800
Subject: [9] RFR (S): 8022263: use same Clang warnings on BSD as on Linux
Message-ID: <B4DD7162-134A-4456-A97E-96F9CB697F98@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8022263
http://cr.openjdk.java.net/~twisti/8022263/webrev.00/

8022263: use same Clang warnings on BSD as on Linux
Reviewed-by:

Enable the same Clang warnings on BSD as on Linux plus a couple of smaller fixes to make it build.


From vladimir.kozlov at oracle.com  Mon Jan  6 15:16:24 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 06 Jan 2014 15:16:24 -0800
Subject: [9] RFR (S): 8022263: use same Clang warnings on BSD as on Linux
In-Reply-To: <B4DD7162-134A-4456-A97E-96F9CB697F98@oracle.com>
References: <B4DD7162-134A-4456-A97E-96F9CB697F98@oracle.com>
Message-ID: <52CB3948.3010605@oracle.com>

Good.

Vladimir

On 1/6/14 2:57 PM, Christian Thalinger wrote:
> https://bugs.openjdk.java.net/browse/JDK-8022263
> http://cr.openjdk.java.net/~twisti/8022263/webrev.00/
>
> 8022263: use same Clang warnings on BSD as on Linux
> Reviewed-by:
>
> Enable the same Clang warnings on BSD as on Linux plus a couple of smaller fixes to make it build.
>

From igor.veresov at oracle.com  Mon Jan  6 16:06:29 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 6 Jan 2014 16:06:29 -0800
Subject: [9] RFR (S): 8022263: use same Clang warnings on BSD as on Linux
In-Reply-To: <B4DD7162-134A-4456-A97E-96F9CB697F98@oracle.com>
References: <B4DD7162-134A-4456-A97E-96F9CB697F98@oracle.com>
Message-ID: <15F76A3D-C5B1-4884-9F93-3EEB054982F7@oracle.com>

Looks fine.

igor

On Jan 6, 2014, at 2:57 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8022263
> http://cr.openjdk.java.net/~twisti/8022263/webrev.00/
> 
> 8022263: use same Clang warnings on BSD as on Linux
> Reviewed-by:
> 
> Enable the same Clang warnings on BSD as on Linux plus a couple of smaller fixes to make it build.
> 


From christian.thalinger at oracle.com  Mon Jan  6 16:27:07 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 6 Jan 2014 16:27:07 -0800
Subject: [9] RFR (S): 8022263: use same Clang warnings on BSD as on Linux
In-Reply-To: <15F76A3D-C5B1-4884-9F93-3EEB054982F7@oracle.com>
References: <B4DD7162-134A-4456-A97E-96F9CB697F98@oracle.com>
	<15F76A3D-C5B1-4884-9F93-3EEB054982F7@oracle.com>
Message-ID: <F531323D-BF3D-4ECD-894F-059B95BAE8A4@oracle.com>

Thanks, Vladimir and Igor.

On Jan 6, 2014, at 4:06 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> Looks fine.
> 
> igor
> 
> On Jan 6, 2014, at 2:57 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> https://bugs.openjdk.java.net/browse/JDK-8022263
>> http://cr.openjdk.java.net/~twisti/8022263/webrev.00/
>> 
>> 8022263: use same Clang warnings on BSD as on Linux
>> Reviewed-by:
>> 
>> Enable the same Clang warnings on BSD as on Linux plus a couple of smaller fixes to make it build.
>> 
> 


From david.holmes at oracle.com  Mon Jan  6 20:37:11 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 07 Jan 2014 14:37:11 +1000
Subject: RFR: 8030350: Enable additional compiler warnings for GCC
In-Reply-To: <0613FFEF-9C8F-4ADD-B148-8D9A6B2EE168@oracle.com>
References: <09B1187E-9549-486E-A181-02F811C524E1@oracle.com>
	<0613FFEF-9C8F-4ADD-B148-8D9A6B2EE168@oracle.com>
Message-ID: <52CB8477.7000607@oracle.com>

late to the party ...

If these generate new warnings has an issue been opened to address them?

Thanks,
David

On 19/12/2013 8:23 AM, Mike Duigou wrote:
> In response to feedback from Dmitry and Christian I have updated the webrev:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8030350/1/webrev/
>
> to now use the -Wformat=2 option and to also enable the option for BSD builds.
>
> Thanks,
>
> Mike
>
> On Dec 17 2013, at 16:08 , Mike Duigou <mike.duigou at oracle.com> wrote:
>
>> Hello all;
>>
>> This is a change which enables additional compiler warnings for native compilation when using GCC. The (-Wformat -Wformat-security) options are supported by GCC 3.0.4 (the earliest version I checked, c. February 2002) and later so we shouldn't see issues with incompatibility.- Wextra appears to have been added in GCC 3.4.X line (c. 2004) so it should also be reasonably well adopted and replaces -W.
>>
>> The core of the change is to add :
>>
>> -Wextra -Wno-unused-parameter -Wformat -Wformat-security
>>
>> for general C and CC++ compilations. For HotSpot C++ compiles a slightly less aggressive set is used:
>>
>> -Wformat -Wformat-security
>>
>> is used.
>>
>> Webrev here:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8030350/0/webrev/
>>
>> For the curious, yes, the additional checks do generate additional warnings. ;-)
>>
>> This change is targeted at the JDK 9 repos but could be backported to JDK 8 fairly easily/safely.
>>
>> Mike
>

From david.holmes at oracle.com  Mon Jan  6 21:02:08 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 07 Jan 2014 15:02:08 +1000
Subject: RFR: JDK-8030796: Update hotspot jprt.properties to release jdk9
In-Reply-To: <52C1F702.8070608@oracle.com>
References: <52B2E6FF.4050701@oracle.com>	<2F7B39DF-9FFB-4CDB-8482-E05D8D6C0131@oracle.com>	<52B2F01B.10407@oracle.com>	<52B2F197.4090000@oracle.com>
	<52B32C48.3000402@oracle.com> <52C1F702.8070608@oracle.com>
Message-ID: <52CB8A50.10303@oracle.com>

On 31/12/2013 8:43 AM, Coleen Phillimore wrote:
>
> Erik,
> I'm confused by this - since hsx is no longer supported, can you just
> change jdk8 to jdk9 and delete the other releases from this file?

There is a lot of legacy stuff (even beyond hsx) in jprt.properties that 
could/should be cleaned out in my opinion.

David

Do
> you need a sponsor?
> thanks,
> Coleen
>
> On 12/19/2013 12:26 PM, Tim Bell wrote:
>> Hi Erik:
>>
>>> So for the hotspot change, please consider this a new review.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030796
>>> Webrev: http://cr.openjdk.java.net/~erikj/8030793/webrev.01/
>>
>> Looks good to me.
>>
>> /Tim
>>
>>> On 2013-12-19 14:09, Erik Joelsson wrote:
>>>> Thanks for the review,
>>>>
>>>> Since the root repo part of this change is quite urgent, I split out
>>>> a new bug for the Hotspot part, which also might warrant more
>>>> discussion.
>>>>
>>>> /Erik
>>>>
>>>> On 2013-12-19 13:51, Chris Hegarty wrote:
>>>>> Looks good to me. Thanks Eric.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 19 Dec 2013, at 12:30, Erik Joelsson <erik.joelsson at oracle.com>
>>>>> wrote:
>>>>>
>>>>>> Please review these changes to make/jprt.poperties and
>>>>>> hotspot/make/jprt.properties. I've just added a jdk9 configuration
>>>>>> to JPRT and this change is needed for JDK 9 to start using it.
>>>>>> This will solve the issue of requiring a jdk8 boot when building
>>>>>> in JPRT.
>>>>>>
>>>>>> In the hotspot version of the file, there is a lot of separate
>>>>>> configuration for jdk7 and jdk8. I didn't dare touch this now and
>>>>>> opted to just add the jdk9 version of these variables. I would
>>>>>> guess that this won't be necessary however since hotspot won't be
>>>>>> delivered to multiple jdk releases anymore?
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8030793/webrev.01/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030793
>>>>>>
>>>>>> I'm still unclear on where the hotspot change needs to go and if I
>>>>>> need a separate bug for it? My interpretation is that the root
>>>>>> repo change should go to jdk9/dev and the hotspot change to
>>>>>> jdk9/hs-rt and that since these changes are using separate routes,
>>>>>> a separate bug should be used. I also assume that as a jdk9
>>>>>> reviewer, I will be able to push this myself (after review) to the
>>>>>> hotspot repo.
>>>>>>
>>>>>> /Erik
>>>>
>>>
>>
>

From david.holmes at oracle.com  Mon Jan  6 21:28:12 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 07 Jan 2014 15:28:12 +1000
Subject: RR(S) 8030941: Darwin mapfile-vers doesn't work for other BSD
In-Reply-To: <52B5C32F.1070302@oracle.com>
References: <52B5C32F.1070302@oracle.com>
Message-ID: <52CB906C.60808@oracle.com>

Hi Dmitry,

I didn't see any reviews of this ...

On 22/12/2013 2:34 AM, Dmitry Samersoff wrote:
> Hi Everybody,
>
> I'd debug out last blocker for clear build of hotspot on FreeBSD.
>
> Darwin's mapfile-vers couldn't be used for FreeBSD (and probably other
> BSDs) so changed makefiles to use generic one if we are not on Darwin.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8030941/webrev.01/

Seems okay to me.


> PS:
>
> As mapfile-vers is essentially the same for all platforms except Darwin
> it might make sense to create a separate directory and put it to a
> single place.

There have been some differences between platforms in the past but we 
may have cleaned all of those up now. Darwin/osx was the only build that 
complained about non-existent symbols listed in the map file.

David

From david.holmes at oracle.com  Mon Jan  6 22:33:18 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 07 Jan 2014 16:33:18 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
Message-ID: <52CB9FAE.80800@oracle.com>

Hi Goetz,

Happy New year! :)

I'm backing up a step now that I have a better grip on the IRIW issue.

On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> ok, I understand the tests are wrong.  It's good this issue is settled.
> Thanks Aleksey and Andreas for going into the details of the proof!
>
> About our change:  David, the causality is the other way round.
> The change is about IRIW.
> 1. To pass IRIW, we must use sync instructions before loads.

Okay I see this (though I think we need to kill IRIW as a requirement 
and I don't think IRIW should form part of any conformance test).

> 2. If we do syncs before loads, we don't need to do them after stores.

True for the IRIW case but to prevent local reordering of volatile 
stores don't you still need some form of "storestore" barrier?

initially: x = 0; y = 0
Thread 0:        Thread 1:
   x = 1            r1 = x
   y = 1            r2 = y
---------------------------
Should be Forbidden: r1 = 0 ^ r2 = 1

You can add the sync after each read but that doesn't prevent the stores 
in thread 0 from being locally re-ordered. So I think you still need at 
least lwsync on the writer side:

initially: x = 0; y = 0
Thread 0:        Thread 1:
   x = 1            r1 = x
   lwsync           sync
   y = 1            r2 = y
                    sync
---------------------------
Forbidden: r1 = 0 ^ r2 = 1

David
-----

> 3. If we don't do them after stores, we fail the volatile constructor tests.
> 4. So finally we added them again at the end of the constructor after stores
>       to pass the volatile constructor tests.
>
> We originally passed the constructor tests because the ppc memory order
> instructions are not as find-granular as the
> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
> MemBarVolatile after the store fixes the constructor tests.  The proper representation
> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
> anyways.
>
>> I'm not happy with the ifdef approach but I won't block it.
> I'd be happy to add a property
>    OrderAccess::cpu_is_multiple_copy_atomic()
> or the like to guard the customization.  I'd like that much better. Or also
>     OrderAccess::needs_support_iriw_ordering()
>     VM_Version::needs_support_iriw_ordering()
>
>
> Best regards,
>    Goetz.
>
>
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 28. November 2013 00:34
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> TL;DR version:
>
> Discussion on the c-i list has now confirmed that a constructor-barrier
> for volatiles is not required as part of the JMM specification. It *may*
> be required in an implementation that doesn't pre-zero memory to ensure
> you can't see uninitialized fields. So the tests for this are invalid
> and this part of the patch is not needed in general (ppc64 may need it
> due to other factors).
>
> Re: "multiple copy atomicity" - first thanks for correcting the term :)
> Second thanks for the reference to that paper! For reference:
>
> "The memory system (perhaps involving a hierarchy of buffers and a
> complex interconnect) does not guarantee that a write becomes visible to
> all other hardware threads at the same time point; these architectures
> are not multiple-copy atomic."
>
> This is the visibility issue that I referred to and affects both ARM and
> PPC. But of course it is normally handled by using suitable barriers
> after the stores that need to be visible. I think the crux of the
> current issue is what you wrote below:
>
>   > The fixes for the constructor issue are only needed because we
>   > remove the sync instruction from behind stores (parse3.cpp:320)
>   > and place it before loads.
>
> I hadn't grasped this part. Obviously if you fail to do the sync after
> the store then you have to do something around the loads to get the same
> results! I still don't know what lead you to the conclusion that the
> only way to fix the IRIW issue was to put the fence before the load -
> maybe when I get the chance to read that paper in full it will be clearer.
>
> So ... the basic problem is that the current structure in the VM has
> hard-wired one choice of how to get the right semantics for volatile
> variables. You now want to customize that but not all the requisite
> hooks are present. It would be better if volatile_load and
> volatile_store were factored out so that they could be implemented as
> desired per-platform. Alternatively there could be pre- and post- hooks
> that could then be customized per platform. Otherwise you need
> platform-specific ifdef's to handle it as per your patch.
>
> I'm not happy with the ifdef approach but I won't block it. I think this
> is an area where a lot of clean up is needed in the VM. The barrier
> abstractions are a confused mess in my opinion.
>
> Thanks,
> David
> -----
>
> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I updated the webrev to fix the issues mentioned by Vladimir:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>
>> I did not yet add the
>>      OrderAccess::needs_support_iriw_ordering()
>>      VM_Version::needs_support_iriw_ordering()
>> or
>>     OrderAccess::cpu_is_multiple_copy_atomic()
>> to reduce #defined, as I got no further comment on that.
>>
>>
>> WRT to the validity of the tests and the interpretation of the JMM
>> I feel not in the position to contribute substantially.
>>
>> But we would like to pass the torture test suite as we consider
>> this a substantial task in implementing a PPC port.  Also we think
>> both tests show behavior a programmer would expect.  It's bad if
>> Java code runs fine on the more common x86 platform, and then
>> fails on ppc.  This will always first be blamed on the VM.
>>
>> The fixes for the constructor issue are only needed because we
>> remove the sync instruction from behind stores (parse3.cpp:320)
>> and place it before loads.  Then there is no sync between volatile store
>> and publishing the object.  So we add it again in this one case
>> (volatile store in constructor).
>>
>>
>> @David
>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>> and that's being discussed now for almost a year.
>>> It may have started a year ago but work on it has hardly been continuous.
>> That's not true, we did a lot of investigation and testing on this issue.
>> And we came up with a solution we consider the best possible. If you
>> have objections, you should at least give the draft of a better solution,
>> we would volunteer to implement and test it.
>> Similarly, we invested time in fixing the concurrency torture issues.
>>
>> @David
>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>> can't find any reference to it.
>> We learned about this reading "A Tutorial Introduction to the ARM and
>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>
>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>
>> Best regards and thanks for all your involvements,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Mittwoch, 27. November 2013 12:53
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz,
>>
>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> -- Volatile in constuctor
>>>> AFAIK we have not seen those tests fail due to a
>>>> missing constructor barrier.
>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>
>> And see follow ups - the tests are invalid.
>>
>>> -- IRIW issue
>>>> I can not possibly answer to the necessary level of detail with a few
>>>> moments thought.
>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>> and that's being discussed now for almost a year.
>>
>> It may have started a year ago but work on it has hardly been continuous.
>>
>>>> You are implying there is a problem here that will
>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>> (I don't really know about ARM, though).
>>> So if I can write down a nicer solution testing for methods that are evaluated
>>> by the C-compiler I'm happy.
>>>
>>> The problem is not that IRIW is not handled by the JMM, the problem
>>> is that
>>>      store
>>>      sync
>>> does not assure multiple-read-atomicity,
>>> only
>>>      sync
>>>      load
>>> does so on PPC.  And you require multiple-read-atomicity to
>>> pass that test.
>>
>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>> can't find any reference to it.
>>
>> Thanks,
>> David
>>
>>      The JMM is fine. And
>>>      store
>>>      MemBarVolatile
>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>> do what is required.
>>>
>>> So if you are off soon, please let's come to a solution that
>>> might be improvable in the way it's implemented, but that
>>> allows us to implement a correct PPC64 port.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>> To: Lindenmaier, Goetz
>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>> Hi everybody,
>>>>
>>>> thanks a lot for the detailed reviews!
>>>> I'll try to answer to all in one mail.
>>>>
>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>> We don't think it's correct if we omit the barrier after initializing
>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>> and Doug Lea, and they agreed.
>>>> Also, concurrency torture tests
>>>>        LongVolatileTest
>>>>        AtomicIntegerInitialValueTest
>>>> will fail.
>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>
>>> The affects of unsafe publication are always surprising - volatiles do
>>> not add anything special here. AFAIK there is nothing in the JMM that
>>> requires the constructor barrier - discussions with Doug and Aleksey
>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>> missing constructor barrier.
>>>
>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>> see a way to implement this cheaper.
>>>>
>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>> Basically, I agree on this.  But you also have to take into account
>>>> that due to the different memory ordering instructions on different platforms
>>>> just implementing something empty is not sufficient.
>>>> An example:
>>>>       MemBarRelease    // means LoadStore, StoreStore barrier
>>>>       MemBarVolatile    // means  StoreLoad barrier
>>>> If these are consecutively in the code, sparc code looks like this:
>>>>       MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>       MemBarVolatile --> membar(Assembler::StoreLoad)
>>>> Just doing what is required.
>>>> On Power, we get suboptimal code, as there are no comparable,
>>>> fine grained operations:
>>>>        MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>       MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>> MemBarRelease empty, as it is also used independently.
>>>>
>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>
>>>> I would propose to guard the code by
>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>> Else, David, how would you propose to implement this platform independent?
>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>
>>> I can not possibly answer to the necessary level of detail with a few
>>> moments thought. You are implying there is a problem here that will
>>> impact numerous platforms (unless you can tell me why ppc is so
>>> different?) and I can not take that on face value at the moment. The
>>> only reason I can see IRIW not being handled by the JMM requirements for
>>> volatile accesses is if there are global visibility issues that are not
>>> addressed - but even then I would expect heavy barriers at the store
>>> would deal with that, not at the load. (This situation reminds me of the
>>> need for read-barriers on Alpha architecture due to the use of software
>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>> that on ppc!)
>>>
>>> Sorry - There is no quick resolution here and in a couple of days I will
>>> be heading out on vacation for two weeks.
>>>
>>> David
>>> -----
>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>> -- Other ports:
>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>
>>>> -- MemBarStoreStore after initialization
>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>> prepare an extra webrev for hotspot-comp.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>> To: Vladimir Kozlov
>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>
>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>> I have to ask David to do correctness evaluation.
>>>>
>>>>      From what I understand what we see here is an attempt to fix an
>>>> existing issue with the implementation of volatiles so that the IRIW
>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>> load.
>>>>
>>>> Now if this was purely handled in ppc64 source code then I would be
>>>> happy to let them do whatever they like (surely this kills performance
>>>> though!). But I do not agree with the changes to the shared code that
>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>> polluting the shared code. My concern is similar to what I said with the
>>>> taskQueue changes - these algorithms should be expressed using the
>>>> correct OrderAccess operations to guarantee the desired properties
>>>> independent of architecture. If such a "barrier" is not needed on a
>>>> given architecture then the implementation in OrderAccess should reduce
>>>> to a no-op.
>>>>
>>>> And as Vitaly points out the constructor barriers are not needed under
>>>> the JMM.
>>>>
>>>>> I am fine with suggested changes because you did not change our current
>>>>> code for our platforms (please, do not change do_exits() now).
>>>>> But may be it should be done using more general query which is set
>>>>> depending on platform:
>>>>>
>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>
>>>>> or similar to what we use now:
>>>>>
>>>>> VM_Version::needs_support_iriw_ordering()
>>>>
>>>> Every platform has to support IRIW this is simply part of the Java
>>>> Memory Model, there should not be any need to call this out explicitly
>>>> like this.
>>>>
>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>      From what I understand our ppc port is also affected. David?
>>>>
>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>
>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>
>>>>> In do_put_xxx() can you combine your changes:
>>>>>
>>>>>         if (is_vol) {
>>>>>           // See comment in do_get_xxx().
>>>>> #ifndef PPC64
>>>>>           insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>> #else
>>>>>           if (is_field) {
>>>>>             // Add MemBarRelease for constructors which write volatile field
>>>>> (PPC64).
>>>>>             set_wrote_volatile(true);
>>>>>           }
>>>>> #endif
>>>>>         }
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>> the torture test suite:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>
>>>>>> Example:
>>>>>> volatile x=0, y=0
>>>>>>        __________    __________    __________    __________
>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>
>>>>>>         write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>                       read(y)                     read(x)
>>>>>>
>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>
>>>>>>
>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>
>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>
>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>> written in constructors are visible before the reference gets
>>>>>> published.
>>>>>>
>>>>>>
>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>> strong.
>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>> What do you think?
>>>>>>
>>>>>> Please review and test this change.
>>>>>>
>>>>>> Best regards,
>>>>>>        Goetz.
>>>>>>

From dmitry.samersoff at oracle.com  Mon Jan  6 23:55:41 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 07 Jan 2014 11:55:41 +0400
Subject: RR(S) 8030941: Darwin mapfile-vers doesn't work for other BSD
In-Reply-To: <52CB906C.60808@oracle.com>
References: <52B5C32F.1070302@oracle.com> <52CB906C.60808@oracle.com>
Message-ID: <52CBB2FD.2030002@oracle.com>

David,

Thank you!

-Dmitry

On 2014-01-07 09:28, David Holmes wrote:
> Hi Dmitry,
> 
> I didn't see any reviews of this ...
> 
> On 22/12/2013 2:34 AM, Dmitry Samersoff wrote:
>> Hi Everybody,
>>
>> I'd debug out last blocker for clear build of hotspot on FreeBSD.
>>
>> Darwin's mapfile-vers couldn't be used for FreeBSD (and probably other
>> BSDs) so changed makefiles to use generic one if we are not on Darwin.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030941/webrev.01/
> 
> Seems okay to me.
> 
> 
>> PS:
>>
>> As mapfile-vers is essentially the same for all platforms except Darwin
>> it might make sense to create a separate directory and put it to a
>> single place.
> 
> There have been some differences between platforms in the past but we
> may have cleaned all of those up now. Darwin/osx was the only build that
> complained about non-existent symbols listed in the map file.
> 
> David


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From staffan.larsen at oracle.com  Tue Jan  7 01:08:20 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 7 Jan 2014 10:08:20 +0100
Subject: RR(S) 8030941: Darwin mapfile-vers doesn't work for other BSD
In-Reply-To: <52B5C32F.1070302@oracle.com>
References: <52B5C32F.1070302@oracle.com>
Message-ID: <AF3C5658-B23C-4A24-9F7F-AC19AD5C19F0@oracle.com>

Looks good!

Thanks,
/Staffan

On 21 dec 2013, at 17:34, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:

> Hi Everybody,
> 
> I'd debug out last blocker for clear build of hotspot on FreeBSD.
> 
> Darwin's mapfile-vers couldn't be used for FreeBSD (and probably other
> BSDs) so changed makefiles to use generic one if we are not on Darwin.
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8030941/webrev.01/
> 
> PS:
> 
> As mapfile-vers is essentially the same for all platforms except Darwin
> it might make sense to create a separate directory and put it to a
> single place.
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.


From goetz.lindenmaier at sap.com  Tue Jan  7 01:10:09 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 7 Jan 2014 09:10:09 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52CB9FAE.80800@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52CB9FAE.80800@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8A82A@DEWDFEMB12A.global.corp.sap>

Hi David,

happy new year for you too!

The compiler uses the following operations for volatiles:

MemBarRelease --> lwsync           
Store                                                       Load
MemBarVolatile --> sync               MemBarAcquire --> lwsync

With our change we get:

MemBarRelease --> lwsync           MemBarVolatile --> sync               
Store                                                       Load
                                                                  MemBarAcquire --> lwsync

So the lwsync in your example is added by the MemBarRelease before the
Store.

Best regards,
  Goetz.


-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 7. Januar 2014 07:33
To: Lindenmaier, Goetz
Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Hi Goetz,

Happy New year! :)

I'm backing up a step now that I have a better grip on the IRIW issue.

On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> ok, I understand the tests are wrong.  It's good this issue is settled.
> Thanks Aleksey and Andreas for going into the details of the proof!
>
> About our change:  David, the causality is the other way round.
> The change is about IRIW.
> 1. To pass IRIW, we must use sync instructions before loads.

Okay I see this (though I think we need to kill IRIW as a requirement 
and I don't think IRIW should form part of any conformance test).

> 2. If we do syncs before loads, we don't need to do them after stores.

True for the IRIW case but to prevent local reordering of volatile 
stores don't you still need some form of "storestore" barrier?

initially: x = 0; y = 0
Thread 0:        Thread 1:
   x = 1            r1 = x
   y = 1            r2 = y
---------------------------
Should be Forbidden: r1 = 0 ^ r2 = 1

You can add the sync after each read but that doesn't prevent the stores 
in thread 0 from being locally re-ordered. So I think you still need at 
least lwsync on the writer side:

initially: x = 0; y = 0
Thread 0:        Thread 1:
   x = 1            r1 = x
   lwsync           sync
   y = 1            r2 = y
                    sync
---------------------------
Forbidden: r1 = 0 ^ r2 = 1

David
-----

> 3. If we don't do them after stores, we fail the volatile constructor tests.
> 4. So finally we added them again at the end of the constructor after stores
>       to pass the volatile constructor tests.
>
> We originally passed the constructor tests because the ppc memory order
> instructions are not as find-granular as the
> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
> MemBarVolatile after the store fixes the constructor tests.  The proper representation
> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
> anyways.
>
>> I'm not happy with the ifdef approach but I won't block it.
> I'd be happy to add a property
>    OrderAccess::cpu_is_multiple_copy_atomic()
> or the like to guard the customization.  I'd like that much better. Or also
>     OrderAccess::needs_support_iriw_ordering()
>     VM_Version::needs_support_iriw_ordering()
>
>
> Best regards,
>    Goetz.
>
>
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 28. November 2013 00:34
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> TL;DR version:
>
> Discussion on the c-i list has now confirmed that a constructor-barrier
> for volatiles is not required as part of the JMM specification. It *may*
> be required in an implementation that doesn't pre-zero memory to ensure
> you can't see uninitialized fields. So the tests for this are invalid
> and this part of the patch is not needed in general (ppc64 may need it
> due to other factors).
>
> Re: "multiple copy atomicity" - first thanks for correcting the term :)
> Second thanks for the reference to that paper! For reference:
>
> "The memory system (perhaps involving a hierarchy of buffers and a
> complex interconnect) does not guarantee that a write becomes visible to
> all other hardware threads at the same time point; these architectures
> are not multiple-copy atomic."
>
> This is the visibility issue that I referred to and affects both ARM and
> PPC. But of course it is normally handled by using suitable barriers
> after the stores that need to be visible. I think the crux of the
> current issue is what you wrote below:
>
>   > The fixes for the constructor issue are only needed because we
>   > remove the sync instruction from behind stores (parse3.cpp:320)
>   > and place it before loads.
>
> I hadn't grasped this part. Obviously if you fail to do the sync after
> the store then you have to do something around the loads to get the same
> results! I still don't know what lead you to the conclusion that the
> only way to fix the IRIW issue was to put the fence before the load -
> maybe when I get the chance to read that paper in full it will be clearer.
>
> So ... the basic problem is that the current structure in the VM has
> hard-wired one choice of how to get the right semantics for volatile
> variables. You now want to customize that but not all the requisite
> hooks are present. It would be better if volatile_load and
> volatile_store were factored out so that they could be implemented as
> desired per-platform. Alternatively there could be pre- and post- hooks
> that could then be customized per platform. Otherwise you need
> platform-specific ifdef's to handle it as per your patch.
>
> I'm not happy with the ifdef approach but I won't block it. I think this
> is an area where a lot of clean up is needed in the VM. The barrier
> abstractions are a confused mess in my opinion.
>
> Thanks,
> David
> -----
>
> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I updated the webrev to fix the issues mentioned by Vladimir:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>
>> I did not yet add the
>>      OrderAccess::needs_support_iriw_ordering()
>>      VM_Version::needs_support_iriw_ordering()
>> or
>>     OrderAccess::cpu_is_multiple_copy_atomic()
>> to reduce #defined, as I got no further comment on that.
>>
>>
>> WRT to the validity of the tests and the interpretation of the JMM
>> I feel not in the position to contribute substantially.
>>
>> But we would like to pass the torture test suite as we consider
>> this a substantial task in implementing a PPC port.  Also we think
>> both tests show behavior a programmer would expect.  It's bad if
>> Java code runs fine on the more common x86 platform, and then
>> fails on ppc.  This will always first be blamed on the VM.
>>
>> The fixes for the constructor issue are only needed because we
>> remove the sync instruction from behind stores (parse3.cpp:320)
>> and place it before loads.  Then there is no sync between volatile store
>> and publishing the object.  So we add it again in this one case
>> (volatile store in constructor).
>>
>>
>> @David
>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>> and that's being discussed now for almost a year.
>>> It may have started a year ago but work on it has hardly been continuous.
>> That's not true, we did a lot of investigation and testing on this issue.
>> And we came up with a solution we consider the best possible. If you
>> have objections, you should at least give the draft of a better solution,
>> we would volunteer to implement and test it.
>> Similarly, we invested time in fixing the concurrency torture issues.
>>
>> @David
>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>> can't find any reference to it.
>> We learned about this reading "A Tutorial Introduction to the ARM and
>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>
>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>
>> Best regards and thanks for all your involvements,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Mittwoch, 27. November 2013 12:53
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz,
>>
>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> -- Volatile in constuctor
>>>> AFAIK we have not seen those tests fail due to a
>>>> missing constructor barrier.
>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>
>> And see follow ups - the tests are invalid.
>>
>>> -- IRIW issue
>>>> I can not possibly answer to the necessary level of detail with a few
>>>> moments thought.
>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>> and that's being discussed now for almost a year.
>>
>> It may have started a year ago but work on it has hardly been continuous.
>>
>>>> You are implying there is a problem here that will
>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>> (I don't really know about ARM, though).
>>> So if I can write down a nicer solution testing for methods that are evaluated
>>> by the C-compiler I'm happy.
>>>
>>> The problem is not that IRIW is not handled by the JMM, the problem
>>> is that
>>>      store
>>>      sync
>>> does not assure multiple-read-atomicity,
>>> only
>>>      sync
>>>      load
>>> does so on PPC.  And you require multiple-read-atomicity to
>>> pass that test.
>>
>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>> can't find any reference to it.
>>
>> Thanks,
>> David
>>
>>      The JMM is fine. And
>>>      store
>>>      MemBarVolatile
>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>> do what is required.
>>>
>>> So if you are off soon, please let's come to a solution that
>>> might be improvable in the way it's implemented, but that
>>> allows us to implement a correct PPC64 port.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>> To: Lindenmaier, Goetz
>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>> Hi everybody,
>>>>
>>>> thanks a lot for the detailed reviews!
>>>> I'll try to answer to all in one mail.
>>>>
>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>> We don't think it's correct if we omit the barrier after initializing
>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>> and Doug Lea, and they agreed.
>>>> Also, concurrency torture tests
>>>>        LongVolatileTest
>>>>        AtomicIntegerInitialValueTest
>>>> will fail.
>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>
>>> The affects of unsafe publication are always surprising - volatiles do
>>> not add anything special here. AFAIK there is nothing in the JMM that
>>> requires the constructor barrier - discussions with Doug and Aleksey
>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>> missing constructor barrier.
>>>
>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>> see a way to implement this cheaper.
>>>>
>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>> Basically, I agree on this.  But you also have to take into account
>>>> that due to the different memory ordering instructions on different platforms
>>>> just implementing something empty is not sufficient.
>>>> An example:
>>>>       MemBarRelease    // means LoadStore, StoreStore barrier
>>>>       MemBarVolatile    // means  StoreLoad barrier
>>>> If these are consecutively in the code, sparc code looks like this:
>>>>       MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>       MemBarVolatile --> membar(Assembler::StoreLoad)
>>>> Just doing what is required.
>>>> On Power, we get suboptimal code, as there are no comparable,
>>>> fine grained operations:
>>>>        MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>       MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>> MemBarRelease empty, as it is also used independently.
>>>>
>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>
>>>> I would propose to guard the code by
>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>> Else, David, how would you propose to implement this platform independent?
>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>
>>> I can not possibly answer to the necessary level of detail with a few
>>> moments thought. You are implying there is a problem here that will
>>> impact numerous platforms (unless you can tell me why ppc is so
>>> different?) and I can not take that on face value at the moment. The
>>> only reason I can see IRIW not being handled by the JMM requirements for
>>> volatile accesses is if there are global visibility issues that are not
>>> addressed - but even then I would expect heavy barriers at the store
>>> would deal with that, not at the load. (This situation reminds me of the
>>> need for read-barriers on Alpha architecture due to the use of software
>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>> that on ppc!)
>>>
>>> Sorry - There is no quick resolution here and in a couple of days I will
>>> be heading out on vacation for two weeks.
>>>
>>> David
>>> -----
>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>> -- Other ports:
>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>
>>>> -- MemBarStoreStore after initialization
>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>> prepare an extra webrev for hotspot-comp.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>> To: Vladimir Kozlov
>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>
>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>> I have to ask David to do correctness evaluation.
>>>>
>>>>      From what I understand what we see here is an attempt to fix an
>>>> existing issue with the implementation of volatiles so that the IRIW
>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>> load.
>>>>
>>>> Now if this was purely handled in ppc64 source code then I would be
>>>> happy to let them do whatever they like (surely this kills performance
>>>> though!). But I do not agree with the changes to the shared code that
>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>> polluting the shared code. My concern is similar to what I said with the
>>>> taskQueue changes - these algorithms should be expressed using the
>>>> correct OrderAccess operations to guarantee the desired properties
>>>> independent of architecture. If such a "barrier" is not needed on a
>>>> given architecture then the implementation in OrderAccess should reduce
>>>> to a no-op.
>>>>
>>>> And as Vitaly points out the constructor barriers are not needed under
>>>> the JMM.
>>>>
>>>>> I am fine with suggested changes because you did not change our current
>>>>> code for our platforms (please, do not change do_exits() now).
>>>>> But may be it should be done using more general query which is set
>>>>> depending on platform:
>>>>>
>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>
>>>>> or similar to what we use now:
>>>>>
>>>>> VM_Version::needs_support_iriw_ordering()
>>>>
>>>> Every platform has to support IRIW this is simply part of the Java
>>>> Memory Model, there should not be any need to call this out explicitly
>>>> like this.
>>>>
>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>      From what I understand our ppc port is also affected. David?
>>>>
>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>
>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>
>>>>> In do_put_xxx() can you combine your changes:
>>>>>
>>>>>         if (is_vol) {
>>>>>           // See comment in do_get_xxx().
>>>>> #ifndef PPC64
>>>>>           insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>> #else
>>>>>           if (is_field) {
>>>>>             // Add MemBarRelease for constructors which write volatile field
>>>>> (PPC64).
>>>>>             set_wrote_volatile(true);
>>>>>           }
>>>>> #endif
>>>>>         }
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>> the torture test suite:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>
>>>>>> Example:
>>>>>> volatile x=0, y=0
>>>>>>        __________    __________    __________    __________
>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>
>>>>>>         write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>                       read(y)                     read(x)
>>>>>>
>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>
>>>>>>
>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>
>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>
>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>> written in constructors are visible before the reference gets
>>>>>> published.
>>>>>>
>>>>>>
>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>> strong.
>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>> What do you think?
>>>>>>
>>>>>> Please review and test this change.
>>>>>>
>>>>>> Best regards,
>>>>>>        Goetz.
>>>>>>

From david.holmes at oracle.com  Tue Jan  7 01:22:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 07 Jan 2014 19:22:06 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8A82A@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52CB9FAE.80800@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8A82A@DEWDFEMB12A.global.corp.sap>
Message-ID: <52CBC73E.8060501@oracle.com>

On 7/01/2014 7:10 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> happy new year for you too!
>
> The compiler uses the following operations for volatiles:
>
> MemBarRelease --> lwsync
> Store                                                       Load
> MemBarVolatile --> sync               MemBarAcquire --> lwsync
>
> With our change we get:
>
> MemBarRelease --> lwsync           MemBarVolatile --> sync
> Store                                                       Load
>                                                                    MemBarAcquire --> lwsync
>
> So the lwsync in your example is added by the MemBarRelease before the
> Store.

Ah I see. Thanks for clarifying. I need to mull on this a little more.

David

> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 7. Januar 2014 07:33
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi Goetz,
>
> Happy New year! :)
>
> I'm backing up a step now that I have a better grip on the IRIW issue.
>
> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> ok, I understand the tests are wrong.  It's good this issue is settled.
>> Thanks Aleksey and Andreas for going into the details of the proof!
>>
>> About our change:  David, the causality is the other way round.
>> The change is about IRIW.
>> 1. To pass IRIW, we must use sync instructions before loads.
>
> Okay I see this (though I think we need to kill IRIW as a requirement
> and I don't think IRIW should form part of any conformance test).
>
>> 2. If we do syncs before loads, we don't need to do them after stores.
>
> True for the IRIW case but to prevent local reordering of volatile
> stores don't you still need some form of "storestore" barrier?
>
> initially: x = 0; y = 0
> Thread 0:        Thread 1:
>     x = 1            r1 = x
>     y = 1            r2 = y
> ---------------------------
> Should be Forbidden: r1 = 0 ^ r2 = 1
>
> You can add the sync after each read but that doesn't prevent the stores
> in thread 0 from being locally re-ordered. So I think you still need at
> least lwsync on the writer side:
>
> initially: x = 0; y = 0
> Thread 0:        Thread 1:
>     x = 1            r1 = x
>     lwsync           sync
>     y = 1            r2 = y
>                      sync
> ---------------------------
> Forbidden: r1 = 0 ^ r2 = 1
>
> David
> -----
>
>> 3. If we don't do them after stores, we fail the volatile constructor tests.
>> 4. So finally we added them again at the end of the constructor after stores
>>        to pass the volatile constructor tests.
>>
>> We originally passed the constructor tests because the ppc memory order
>> instructions are not as find-granular as the
>> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
>> MemBarVolatile after the store fixes the constructor tests.  The proper representation
>> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
>> anyways.
>>
>>> I'm not happy with the ifdef approach but I won't block it.
>> I'd be happy to add a property
>>     OrderAccess::cpu_is_multiple_copy_atomic()
>> or the like to guard the customization.  I'd like that much better. Or also
>>      OrderAccess::needs_support_iriw_ordering()
>>      VM_Version::needs_support_iriw_ordering()
>>
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 28. November 2013 00:34
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> TL;DR version:
>>
>> Discussion on the c-i list has now confirmed that a constructor-barrier
>> for volatiles is not required as part of the JMM specification. It *may*
>> be required in an implementation that doesn't pre-zero memory to ensure
>> you can't see uninitialized fields. So the tests for this are invalid
>> and this part of the patch is not needed in general (ppc64 may need it
>> due to other factors).
>>
>> Re: "multiple copy atomicity" - first thanks for correcting the term :)
>> Second thanks for the reference to that paper! For reference:
>>
>> "The memory system (perhaps involving a hierarchy of buffers and a
>> complex interconnect) does not guarantee that a write becomes visible to
>> all other hardware threads at the same time point; these architectures
>> are not multiple-copy atomic."
>>
>> This is the visibility issue that I referred to and affects both ARM and
>> PPC. But of course it is normally handled by using suitable barriers
>> after the stores that need to be visible. I think the crux of the
>> current issue is what you wrote below:
>>
>>    > The fixes for the constructor issue are only needed because we
>>    > remove the sync instruction from behind stores (parse3.cpp:320)
>>    > and place it before loads.
>>
>> I hadn't grasped this part. Obviously if you fail to do the sync after
>> the store then you have to do something around the loads to get the same
>> results! I still don't know what lead you to the conclusion that the
>> only way to fix the IRIW issue was to put the fence before the load -
>> maybe when I get the chance to read that paper in full it will be clearer.
>>
>> So ... the basic problem is that the current structure in the VM has
>> hard-wired one choice of how to get the right semantics for volatile
>> variables. You now want to customize that but not all the requisite
>> hooks are present. It would be better if volatile_load and
>> volatile_store were factored out so that they could be implemented as
>> desired per-platform. Alternatively there could be pre- and post- hooks
>> that could then be customized per platform. Otherwise you need
>> platform-specific ifdef's to handle it as per your patch.
>>
>> I'm not happy with the ifdef approach but I won't block it. I think this
>> is an area where a lot of clean up is needed in the VM. The barrier
>> abstractions are a confused mess in my opinion.
>>
>> Thanks,
>> David
>> -----
>>
>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>
>>> I did not yet add the
>>>       OrderAccess::needs_support_iriw_ordering()
>>>       VM_Version::needs_support_iriw_ordering()
>>> or
>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>> to reduce #defined, as I got no further comment on that.
>>>
>>>
>>> WRT to the validity of the tests and the interpretation of the JMM
>>> I feel not in the position to contribute substantially.
>>>
>>> But we would like to pass the torture test suite as we consider
>>> this a substantial task in implementing a PPC port.  Also we think
>>> both tests show behavior a programmer would expect.  It's bad if
>>> Java code runs fine on the more common x86 platform, and then
>>> fails on ppc.  This will always first be blamed on the VM.
>>>
>>> The fixes for the constructor issue are only needed because we
>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>> and place it before loads.  Then there is no sync between volatile store
>>> and publishing the object.  So we add it again in this one case
>>> (volatile store in constructor).
>>>
>>>
>>> @David
>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>> and that's being discussed now for almost a year.
>>>> It may have started a year ago but work on it has hardly been continuous.
>>> That's not true, we did a lot of investigation and testing on this issue.
>>> And we came up with a solution we consider the best possible. If you
>>> have objections, you should at least give the draft of a better solution,
>>> we would volunteer to implement and test it.
>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>
>>> @David
>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>> can't find any reference to it.
>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>
>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>>
>>> Best regards and thanks for all your involvements,
>>>      Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Mittwoch, 27. November 2013 12:53
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>> Hi David,
>>>>
>>>> -- Volatile in constuctor
>>>>> AFAIK we have not seen those tests fail due to a
>>>>> missing constructor barrier.
>>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>
>>> And see follow ups - the tests are invalid.
>>>
>>>> -- IRIW issue
>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>> moments thought.
>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>> and that's being discussed now for almost a year.
>>>
>>> It may have started a year ago but work on it has hardly been continuous.
>>>
>>>>> You are implying there is a problem here that will
>>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>>> (I don't really know about ARM, though).
>>>> So if I can write down a nicer solution testing for methods that are evaluated
>>>> by the C-compiler I'm happy.
>>>>
>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>> is that
>>>>       store
>>>>       sync
>>>> does not assure multiple-read-atomicity,
>>>> only
>>>>       sync
>>>>       load
>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>> pass that test.
>>>
>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>> can't find any reference to it.
>>>
>>> Thanks,
>>> David
>>>
>>>       The JMM is fine. And
>>>>       store
>>>>       MemBarVolatile
>>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>>> do what is required.
>>>>
>>>> So if you are off soon, please let's come to a solution that
>>>> might be improvable in the way it's implemented, but that
>>>> allows us to implement a correct PPC64 port.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>> Hi everybody,
>>>>>
>>>>> thanks a lot for the detailed reviews!
>>>>> I'll try to answer to all in one mail.
>>>>>
>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>>> We don't think it's correct if we omit the barrier after initializing
>>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>>> and Doug Lea, and they agreed.
>>>>> Also, concurrency torture tests
>>>>>         LongVolatileTest
>>>>>         AtomicIntegerInitialValueTest
>>>>> will fail.
>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>>
>>>> The affects of unsafe publication are always surprising - volatiles do
>>>> not add anything special here. AFAIK there is nothing in the JMM that
>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>> missing constructor barrier.
>>>>
>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>>> see a way to implement this cheaper.
>>>>>
>>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>>> Basically, I agree on this.  But you also have to take into account
>>>>> that due to the different memory ordering instructions on different platforms
>>>>> just implementing something empty is not sufficient.
>>>>> An example:
>>>>>        MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>        MemBarVolatile    // means  StoreLoad barrier
>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>        MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>>        MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>> Just doing what is required.
>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>> fine grained operations:
>>>>>         MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>>        MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>>> MemBarRelease empty, as it is also used independently.
>>>>>
>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>
>>>>> I would propose to guard the code by
>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>> Else, David, how would you propose to implement this platform independent?
>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>
>>>> I can not possibly answer to the necessary level of detail with a few
>>>> moments thought. You are implying there is a problem here that will
>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>> different?) and I can not take that on face value at the moment. The
>>>> only reason I can see IRIW not being handled by the JMM requirements for
>>>> volatile accesses is if there are global visibility issues that are not
>>>> addressed - but even then I would expect heavy barriers at the store
>>>> would deal with that, not at the load. (This situation reminds me of the
>>>> need for read-barriers on Alpha architecture due to the use of software
>>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>>> that on ppc!)
>>>>
>>>> Sorry - There is no quick resolution here and in a couple of days I will
>>>> be heading out on vacation for two weeks.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>> -- Other ports:
>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>
>>>>> -- MemBarStoreStore after initialization
>>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>>> prepare an extra webrev for hotspot-comp.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>> To: Vladimir Kozlov
>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>>
>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>> I have to ask David to do correctness evaluation.
>>>>>
>>>>>       From what I understand what we see here is an attempt to fix an
>>>>> existing issue with the implementation of volatiles so that the IRIW
>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>>> load.
>>>>>
>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>> happy to let them do whatever they like (surely this kills performance
>>>>> though!). But I do not agree with the changes to the shared code that
>>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>>> polluting the shared code. My concern is similar to what I said with the
>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>> given architecture then the implementation in OrderAccess should reduce
>>>>> to a no-op.
>>>>>
>>>>> And as Vitaly points out the constructor barriers are not needed under
>>>>> the JMM.
>>>>>
>>>>>> I am fine with suggested changes because you did not change our current
>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>> But may be it should be done using more general query which is set
>>>>>> depending on platform:
>>>>>>
>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>
>>>>>> or similar to what we use now:
>>>>>>
>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>
>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>> Memory Model, there should not be any need to call this out explicitly
>>>>> like this.
>>>>>
>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>>       From what I understand our ppc port is also affected. David?
>>>>>
>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>>
>>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>
>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>
>>>>>>          if (is_vol) {
>>>>>>            // See comment in do_get_xxx().
>>>>>> #ifndef PPC64
>>>>>>            insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>> #else
>>>>>>            if (is_field) {
>>>>>>              // Add MemBarRelease for constructors which write volatile field
>>>>>> (PPC64).
>>>>>>              set_wrote_volatile(true);
>>>>>>            }
>>>>>> #endif
>>>>>>          }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>>> the torture test suite:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>
>>>>>>> Example:
>>>>>>> volatile x=0, y=0
>>>>>>>         __________    __________    __________    __________
>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>
>>>>>>>          write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>                        read(y)                     read(x)
>>>>>>>
>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>
>>>>>>>
>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>
>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>
>>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>>> written in constructors are visible before the reference gets
>>>>>>> published.
>>>>>>>
>>>>>>>
>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>>> strong.
>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Please review and test this change.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>         Goetz.
>>>>>>>

From goetz.lindenmaier at sap.com  Tue Jan  7 08:49:23 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 7 Jan 2014 16:49:23 +0000
Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding.
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap>

Hi,

This change contains a row of fixes in the ppc and aix coding
we collected over the last testing days.
Please review this change.
http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/

In more detail:

Stack overflow issue: code branched to zero.
Fix: Generate throw_StackOverflowError stub before generating
the native entry.

Fix assertion when looking for nmethod in code cache:
use unsafe accessor. Also optimize: don't look up the
address twice.

Fix compressing klass pointers.

Implement some missing stuff in the aix os branch.

Thanks and best regards,
  Goetz.

From volker.simonis at gmail.com  Tue Jan  7 09:27:37 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 7 Jan 2014 18:27:37 +0100
Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap>
Message-ID: <CA+3eh11P5-tS9FHqQPWZqkjyYCwO+wzW46gEsQ7YtfjLvhMOrQ@mail.gmail.com>

Hi,

we've forgotten a SAP JVM comment in the code in os_aix.cpp in the method:

bool os::find(address addr, outputStream* st)

Sorry, that was my fault. It will be removed in the final version.

Regards,
Volker


On Tue, Jan 7, 2014 at 5:49 PM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi,
>
>
>
> This change contains a row of fixes in the ppc and aix coding
>
> we collected over the last testing days.
>
> Please review this change.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/
>
>
>
> In more detail:
>
>
> Stack overflow issue: code branched to zero.
> Fix: Generate throw_StackOverflowError stub before generating
> the native entry.
>
> Fix assertion when looking for nmethod in code cache:
> use unsafe accessor. Also optimize: don't look up the
> address twice.
>
> Fix compressing klass pointers.
>
> Implement some missing stuff in the aix os branch.
>
>
>
> Thanks and best regards,
>
>   Goetz.

From vladimir.kozlov at oracle.com  Tue Jan  7 09:56:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 07 Jan 2014 09:56:31 -0800
Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap>
Message-ID: <52CC3FCF.3070608@oracle.com>

Looks fine to me. You can push it since it does not affect shared code.

Thanks,
Vladimir

On 1/7/14 8:49 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> This change contains a row of fixes in the ppc and aix coding
>
> we collected over the last testing days.
>
> Please review this change.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/
>
> In more detail:
>
>
> Stack overflow issue: code branched to zero.
> Fix: Generate throw_StackOverflowError stub before generating
> the native entry.
>
> Fix assertion when looking for nmethod in code cache:
> use unsafe accessor. Also optimize: don't look up the
> address twice.
>
> Fix compressing klass pointers.
>
> Implement some missing stuff in the aix os branch.
>
> Thanks and best regards,
>
>    Goetz.
>

From coleen.phillimore at oracle.com  Tue Jan  7 10:25:30 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 07 Jan 2014 13:25:30 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52CB0887.3090903@oracle.com>
References: <52C5A105.6030804@oracle.com> <52C6FCE2.8000906@oracle.com>
	<52C708BD.9090401@oracle.com> <52C7119D.9020601@oracle.com>
	<52C716E3.1000105@oracle.com> <52CB0887.3090903@oracle.com>
Message-ID: <52CC469A.3020008@oracle.com>


Thanks, Jon!
Coleen

On 01/06/2014 02:48 PM, Jon Masamitsu wrote:
> Looks good.
>
> Jon
>
> On 01/03/2014 12:00 PM, Coleen Phillmore wrote:
>>
>> On 1/3/2014 2:38 PM, Jon Masamitsu wrote:
>>>
>>> On 1/3/2014 11:00 AM, Coleen Phillmore wrote:
>>>>
>>>> Jon,  Thanks for reviewing this.
>>>>
>>>> On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
>>>>> Coleen,
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>>>>>
>>>>>
>>>>> 146   bool contains(const void* ptr) { return bottom() < ptr && 
>>>>> ptr <= _top; }
>>>>>
>>>>> I think bottom() points to the first chunk.  Also _top points to 
>>>>> the start
>>>>> of the unallocated space (next place where a chunk will be 
>>>>> allocated).
>>>>> So I would think this should be
>>>>>
>>>>> bool contains(const void* ptr) { return bottom() <=ptr && ptr < 
>>>>> _top; }
>>>>>
>>>>>
>>>>
>>>> Yes, I agree.
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>>>>>
>>>>>
>>>>> Don't you need some locking to protect the "chunks_in_use()" lists?
>>>>>
>>>>> 2382 bool SpaceManager::contains(const void *ptr) {
>>>>> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
>>>>> next_chunk_index(i))
>>>>> 2384   {
>>>>> 2385     Metachunk* curr = chunks_in_use(i);
>>>>> 2386     while (curr != NULL) {
>>>>> 2387       if (curr->contains(ptr)) return true;
>>>>> 2388       curr = curr->next();
>>>>> 2389     }
>>>>> 2390   }
>>>>> 2391   return false;
>>>>> 2392 }
>>>>> 2393
>>>>
>>>> If new chunks are added while this is iterating over them, they are 
>>>> added to the front of the list.  This is ok because we would only 
>>>> call this for metadata that is already allocated in one of the 
>>>> chunks.   I don't want to add a lock but I do need some memory 
>>>> ordering instructions.   I'll move the one that I had on virtual 
>>>> space lists to where we add the chunks.
>>>
>>> Ok.  Do you think it is worth code in set_chunks_in_use() that checks
>>> that the list head is set after the new chunk has been added?
>>>
>>> Something like
>>>
>>> set_chunks_in_use(new_chunk)
>>> if (chunks_in_use() != NULL)
>>>     assert(new_chunk->next == chunks_in_use(), "Always add new chunk 
>>> to list first");
>>> }
>>
>> I think the OrderAccess::storestore() should accomplish this. 
>> chunks_in_use() shouldn't be null after this though except for at 
>> deletion time.   So this code seems overly paranoid about the C++ 
>> compiler not doing the stores.  Actually the C++ compiler could keep 
>> all of this in a register and we'd never see things in the right order.
>>
>> Here's a new version with the OrderAccess::storestore();   I reran 
>> the parallel class loading tests on this.
>>
>> http://cr.openjdk.java.net/~coleenp/8029178_2/ 
>> <http://cr.openjdk.java.net/%7Ecoleenp/8029178_2/>
>>
>> Thanks,
>> Coleen
>>>
>>> Just a thought.
>>>
>>> Jon
>>>
>>>
>>>
>>>>
>>>> The Metaspace/SpaceManager destructors can only be called for the 
>>>> _unloading list, which is created at a safepoint and we don't walk 
>>>> those lists in CLDG::contains.
>>>>
>>>> Thank you for pointing these out.   I'll retest and send out 
>>>> another webrev.
>>>>
>>>> Coleen
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>>>>>> Summary: Metaspace::contains cannot look at purged metaspaces 
>>>>>> while CMS concurrently deallocates them.
>>>>>>
>>>>>> Removed 2 calls to is_metaspace_object where the object may be in 
>>>>>> a deallocated metaspace.  Removed walking virtual space lists for 
>>>>>> determining contains because the virtual space list can change 
>>>>>> concurrently with the walk. CLDG::contains is slower but no 
>>>>>> slowdowns with testing were observed.
>>>>>>
>>>>>> Tested by SQE testbase tests, jtreg tests.   Functional testing 
>>>>>> by parallel class loading tests and 
>>>>>> nsk/coverage/arguments/arguments008 (ie. calls 
>>>>>> Method::is_valid_method)
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Tue Jan  7 10:25:46 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 07 Jan 2014 13:25:46 -0500
Subject: RFR 8029178: Parallel class loading test anonymous-simple gets
	SIGSEGV in Metaspace:,:contains
In-Reply-To: <52CB083C.5010607@oracle.com>
References: <52C5A105.6030804@oracle.com>
	<52C6FCE2.8000906@oracle.com>	<52C708BD.9090401@oracle.com>
	<52C7119D.9020601@oracle.com> <52C716E3.1000105@oracle.com>
	<52CB083C.5010607@oracle.com>
Message-ID: <52CC46AA.5050900@oracle.com>


Thanks!
Coleen

On 01/06/2014 02:47 PM, serguei.spitsyn at oracle.com wrote:
> On 1/3/14 12:00 PM, Coleen Phillmore wrote:
>>
>> On 1/3/2014 2:38 PM, Jon Masamitsu wrote:
>>>
>>> On 1/3/2014 11:00 AM, Coleen Phillmore wrote:
>>>>
>>>> Jon,  Thanks for reviewing this.
>>>>
>>>> On 1/3/2014 1:09 PM, Jon Masamitsu wrote:
>>>>> Coleen,
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metachunk.hpp.frames.html 
>>>>>
>>>>>
>>>>> 146   bool contains(const void* ptr) { return bottom() < ptr && 
>>>>> ptr <= _top; }
>>>>>
>>>>> I think bottom() points to the first chunk.  Also _top points to 
>>>>> the start
>>>>> of the unallocated space (next place where a chunk will be 
>>>>> allocated).
>>>>> So I would think this should be
>>>>>
>>>>> bool contains(const void* ptr) { return bottom() <=ptr && ptr < 
>>>>> _top; }
>>>>>
>>>>>
>>>>
>>>> Yes, I agree.
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8029178/src/share/vm/memory/metaspace.cpp.frames.html 
>>>>>
>>>>>
>>>>> Don't you need some locking to protect the "chunks_in_use()" lists?
>>>>>
>>>>> 2382 bool SpaceManager::contains(const void *ptr) {
>>>>> 2383   for (ChunkIndex i = ZeroIndex; i < NumberOfInUseLists; i = 
>>>>> next_chunk_index(i))
>>>>> 2384   {
>>>>> 2385     Metachunk* curr = chunks_in_use(i);
>>>>> 2386     while (curr != NULL) {
>>>>> 2387       if (curr->contains(ptr)) return true;
>>>>> 2388       curr = curr->next();
>>>>> 2389     }
>>>>> 2390   }
>>>>> 2391   return false;
>>>>> 2392 }
>>>>> 2393
>>>>
>>>> If new chunks are added while this is iterating over them, they are 
>>>> added to the front of the list.  This is ok because we would only 
>>>> call this for metadata that is already allocated in one of the 
>>>> chunks.   I don't want to add a lock but I do need some memory 
>>>> ordering instructions.   I'll move the one that I had on virtual 
>>>> space lists to where we add the chunks.
>>>
>>> Ok.  Do you think it is worth code in set_chunks_in_use() that checks
>>> that the list head is set after the new chunk has been added?
>>>
>>> Something like
>>>
>>> set_chunks_in_use(new_chunk)
>>> if (chunks_in_use() != NULL)
>>>     assert(new_chunk->next == chunks_in_use(), "Always add new chunk 
>>> to list first");
>>> }
>>
>> I think the OrderAccess::storestore() should accomplish this. 
>> chunks_in_use() shouldn't be null after this though except for at 
>> deletion time.   So this code seems overly paranoid about the C++ 
>> compiler not doing the stores.  Actually the C++ compiler could keep 
>> all of this in a register and we'd never see things in the right order.
>>
>> Here's a new version with the OrderAccess::storestore();   I reran 
>> the parallel class loading tests on this.
>>
>> http://cr.openjdk.java.net/~coleenp/8029178_2/ 
>> <http://cr.openjdk.java.net/%7Ecoleenp/8029178_2/>
>
> This looks good to me.
>
> Thanks,
> Serguei
>
>>
>> Thanks,
>> Coleen
>>>
>>> Just a thought.
>>>
>>> Jon
>>>
>>>
>>>
>>>>
>>>> The Metaspace/SpaceManager destructors can only be called for the 
>>>> _unloading list, which is created at a safepoint and we don't walk 
>>>> those lists in CLDG::contains.
>>>>
>>>> Thank you for pointing these out.   I'll retest and send out 
>>>> another webrev.
>>>>
>>>> Coleen
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> On 1/2/2014 9:25 AM, Coleen Phillmore wrote:
>>>>>> Summary: Metaspace::contains cannot look at purged metaspaces 
>>>>>> while CMS concurrently deallocates them.
>>>>>>
>>>>>> Removed 2 calls to is_metaspace_object where the object may be in 
>>>>>> a deallocated metaspace.  Removed walking virtual space lists for 
>>>>>> determining contains because the virtual space list can change 
>>>>>> concurrently with the walk. CLDG::contains is slower but no 
>>>>>> slowdowns with testing were observed.
>>>>>>
>>>>>> Tested by SQE testbase tests, jtreg tests.   Functional testing 
>>>>>> by parallel class loading tests and 
>>>>>> nsk/coverage/arguments/arguments008 (ie. calls 
>>>>>> Method::is_valid_method)
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8029178/
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8029178
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>
>>>>
>>>
>>
>


From goetz.lindenmaier at sap.com  Tue Jan  7 11:21:23 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 7 Jan 2014 19:21:23 +0000
Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding.
In-Reply-To: <52CC3FCF.3070608@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap>
	<52CC3FCF.3070608@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8AB45@DEWDFEMB12A.global.corp.sap>

Hi Vladimir, 

thanks for the review, and for testing the other change
yesterday.

I pushed it, including the fix to the comment.

Best regards,
  Goetz.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Tuesday, January 07, 2014 6:57 PM
To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
Subject: Re: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding.

Looks fine to me. You can push it since it does not affect shared code.

Thanks,
Vladimir

On 1/7/14 8:49 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> This change contains a row of fixes in the ppc and aix coding
>
> we collected over the last testing days.
>
> Please review this change.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/
>
> In more detail:
>
>
> Stack overflow issue: code branched to zero.
> Fix: Generate throw_StackOverflowError stub before generating
> the native entry.
>
> Fix assertion when looking for nmethod in code cache:
> use unsafe accessor. Also optimize: don't look up the
> address twice.
>
> Fix compressing klass pointers.
>
> Implement some missing stuff in the aix os branch.
>
> Thanks and best regards,
>
>    Goetz.
>

From mike.duigou at oracle.com  Tue Jan  7 13:00:36 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 7 Jan 2014 13:00:36 -0800
Subject: RFR: 8030350: Enable additional compiler warnings for GCC
In-Reply-To: <52CB8477.7000607@oracle.com>
References: <09B1187E-9549-486E-A181-02F811C524E1@oracle.com>
	<0613FFEF-9C8F-4ADD-B148-8D9A6B2EE168@oracle.com>
	<52CB8477.7000607@oracle.com>
Message-ID: <E4862691-D486-4C20-8502-269E172E3614@oracle.com>


On Jan 6 2014, at 20:37 , David Holmes <david.holmes at oracle.com> wrote:

> late to the party ...
> 
> If these generate new warnings has an issue been opened to address them?

I haven't yet. My plan was to ensure that before pushing the changes I would ensure that no -Werror directives caused any compilations to fail as a result of enabling the additional warnings and write up bugs for the new warnings.

Mike

> 
> Thanks,
> David
> 
> On 19/12/2013 8:23 AM, Mike Duigou wrote:
>> In response to feedback from Dmitry and Christian I have updated the webrev:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8030350/1/webrev/
>> 
>> to now use the -Wformat=2 option and to also enable the option for BSD builds.
>> 
>> Thanks,
>> 
>> Mike
>> 
>> On Dec 17 2013, at 16:08 , Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>>> Hello all;
>>> 
>>> This is a change which enables additional compiler warnings for native compilation when using GCC. The (-Wformat -Wformat-security) options are supported by GCC 3.0.4 (the earliest version I checked, c. February 2002) and later so we shouldn't see issues with incompatibility.- Wextra appears to have been added in GCC 3.4.X line (c. 2004) so it should also be reasonably well adopted and replaces -W.
>>> 
>>> The core of the change is to add :
>>> 
>>> -Wextra -Wno-unused-parameter -Wformat -Wformat-security
>>> 
>>> for general C and CC++ compilations. For HotSpot C++ compiles a slightly less aggressive set is used:
>>> 
>>> -Wformat -Wformat-security
>>> 
>>> is used.
>>> 
>>> Webrev here:
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8030350/0/webrev/
>>> 
>>> For the curious, yes, the additional checks do generate additional warnings. ;-)
>>> 
>>> This change is targeted at the JDK 9 repos but could be backported to JDK 8 fairly easily/safely.
>>> 
>>> Mike
>> 


From mike.duigou at oracle.com  Tue Jan  7 17:09:25 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 7 Jan 2014 17:09:25 -0800
Subject: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
Message-ID: <ED9E1EFE-F980-4E66-8EAF-C12F180CF1F4@oracle.com>

Hello all;

I have added the BSD supported requested in previous reviews and I believe this change is ready to go in.

http://cr.openjdk.java.net/~mduigou/JDK-8030350/2/webrev/

I need a sponsor for the hotspot repo portion of the change.

I've also generated build log diffs to illuminate the additional warnings produced and will file bugs shortly for a few of the cases.

Mike

From magnus.ihse.bursie at oracle.com  Wed Jan  8 03:57:47 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 08 Jan 2014 12:57:47 +0100
Subject: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
In-Reply-To: <ED9E1EFE-F980-4E66-8EAF-C12F180CF1F4@oracle.com>
References: <ED9E1EFE-F980-4E66-8EAF-C12F180CF1F4@oracle.com>
Message-ID: <52CD3D3B.9050002@oracle.com>

On 2014-01-08 02:09, Mike Duigou wrote:
> Hello all;
>
> I have added the BSD supported requested in previous reviews and I believe this change is ready to go in.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8030350/2/webrev/
>
> I need a sponsor for the hotspot repo portion of the change.
>
> I've also generated build log diffs to illuminate the additional warnings produced and will file bugs shortly for a few of the cases.
>
> Mike

Mike,

There seems to be a problem with the webrev - there are no actual 
changes recorded in it.

/Magnus

From magnus.ihse.bursie at oracle.com  Wed Jan  8 04:28:26 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 08 Jan 2014 13:28:26 +0100
Subject: RFR: 8030350: Enable additional compiler warnings for GCC
In-Reply-To: <52B1AD81.7000707@oracle.com>
References: <09B1187E-9549-486E-A181-02F811C524E1@oracle.com>	<EB5A5DC2-D2AC-4A71-A171-2E134C165083@oracle.com>
	<442FC1D7-C31E-413D-B872-D94156F4F9CD@oracle.com>
	<52B1AD81.7000707@oracle.com>
Message-ID: <52CD446A.70101@oracle.com>

On 2013-12-18 15:13, Dmitry Samersoff wrote:
> Mike,
>
> 1. I'm not sure -Wformat-security has any value for us - it checks for case
>    printf(string) with no extra arguments,
> as it can cause buffer overrun if string comes from untrusted source.

Actually, it checks functions tagged as "format" functions. If you have 
your own implementation with a "printf-style" syntax (typically some 
kind of pre-/post-processing around sprintf etc), you can tag these 
functions as well, using e.g.

  __attribute__ ((format (printf, 2, 3)));


The best way to do this is to define a macro that expands to such an 
attribute definition on gcc, and empty for other compilers.

I have personally found this to be a great tool for catching format 
errors. It do require some initial effort of finding and tagging the 
"printf-style" functions, but then all uses of these are checked.

I do not know, however, if this is applicable to the jdk.

/Magnus

From mike.duigou at oracle.com  Wed Jan  8 13:11:43 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 8 Jan 2014 13:11:43 -0800
Subject: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
In-Reply-To: <52CD3D3B.9050002@oracle.com>
References: <ED9E1EFE-F980-4E66-8EAF-C12F180CF1F4@oracle.com>
	<52CD3D3B.9050002@oracle.com>
Message-ID: <0603017D-7128-4EB0-9551-19979949ED78@oracle.com>

You are correct. Sorry (wrong -r option and use of a file list misled me into thinking it was generating the right content). 

I have added

 http://cr.openjdk.java.net/~mduigou/JDK-8030350/3/webrev/

and checked to make sure it has the right content.

Mike

On Jan 8 2014, at 03:57 , Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

> On 2014-01-08 02:09, Mike Duigou wrote:
>> Hello all;
>> 
>> I have added the BSD supported requested in previous reviews and I believe this change is ready to go in.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8030350/2/webrev/
>> 
>> I need a sponsor for the hotspot repo portion of the change.
>> 
>> I've also generated build log diffs to illuminate the additional warnings produced and will file bugs shortly for a few of the cases.
>> 
>> Mike
> 
> Mike,
> 
> There seems to be a problem with the webrev - there are no actual changes recorded in it.
> 
> /Magnus


From dl at cs.oswego.edu  Wed Jan  8 13:28:24 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 08 Jan 2014 16:28:24 -0500
Subject: JMM9 Project (Java Memory Model revisions for JDK9)
Message-ID: <52CDC2F8.8060408@cs.oswego.edu>


[to hotspot-dev, cross-post to core-libs-dev]

We are proposing the creation of the JMM9 Project with Doug Lea as
the Lead and Hotspot as the sponsoring Group.
JMM9 is unusual as a Project in that it will not produce software,
so there is no suggested initial list of Authors.
The sponsoring Group is also somewhat arbitrary, but Hotspot
seems most directly impacted.  The main participants include academics
and researchers expert in the formal specification of shared-memory
concurrency, along with hardware and software engineers. The tentative
participants are already making progress on identifying problems and
solutions in ad-hoc discussions, so would be grateful to have an
approved home base and mailing list to continue on.

I expect that the Hotspot group lead will send out a Call For Votes
shortly. For now, here is a paste of the JMM9 JEP that might be posted
soon.


Title: JMM9: Java Memory Model for JDK9
Author: Doug Lea
[... other metadata omitted ...]

Summary
-------

This JEP serves to provide information and guidance for JDK9-related
efforts bearing on shared-memory concurrency, including those on
specification updates, JVM concurrency support, JDK components,
testing, and tools.  Engineering and release efforts in these areas
will be subject to other JEPs, that will in turn become components of
one or more JSRs targetted for JDK9. In particular, JLS (chapter 17)
updates require such a JSR.

Motivation
----------

Specifying shared memory consistency models, and developing and
maintaining features and components that operate in accord with them,
are among the most central yet difficult issues in engineering
concurrent and parallel platforms. Specification limitations, errors,
and unintended consequences become apparent over time; new hardware
platforms, programming techniques, and software components and tools
emerge that escape existing boundaries.  This JEP addresses problems
and extends coverage of the Java Memory Model (JMM), last revised for
JDK5 (JSR133).

Description
-----------

Products of this JEP will be placed on the OpenJDK Wiki
(https://wiki.openjdk.java.net/).  The process will mainly take place
on a dedicated openjdk mailing list (jmm9 at openjdk.java.net).  We
expect results to include the following:

1. Improved formalization.  Parts of the underlying model will be
reformulated.  We aim for the revised model to be mechanically
checkable, as well as more readily humanly understandable.  When
phrased in terms of JLS chapter 17 updates, this will also address
existing errors pointed out in a number of academic papers. (For the
earliest, see http://groups.inf.ed.ac.uk/request/jmmexamples.pdf "Java
Memory Model Examples: Good, Bad and Ugly" by David Aspinall and
Jaroslav Sevc?k.)

2. JVM coverage. Existing specifications focus on language-level
constructs. This leaves some issues (for example initialization)
incompletely defined, especially for other languages running on
JVMs. These will be addressed, possibly by basing a core model on a
minimal set of byte codes and intrinsics.

3. Extended scope. Existing specifications explicitly cover Java
Threads, locks, monitors, and volatile and final fields. However,
since JDK5, features have been added that cannot be rigorously
specified in these terms (for example, AtomicX.weakCompareAndSet).
These must be addressed.  We also anticipate that further extensions
may arise in the course of other JDK9 JEPs; possibly including forms
of Atomics that can be embedded into other objects.

4. C11/C++11 compatibility. The C++11 and C11 standards adapted ideas
from the JSR133 JMM spec effort.  However, they also extended them to
cover constructs that have been (or may be) added to Java only after
JSR133 (see above). In part because Java programs may call C native
libraries, it should be the case that equivalent constructs have
compatible specifications across languages. We will further explore
whether cross-language conventions can be established to ensure that
low-level implementations of these constructs are compatible on common
platforms.

5. Implementation guidance. JVM implementors, JDK library developers,
and developers as a whole often find it useful to rely on documents
explaining how the JMM impacts particular problems and solutions. We
intend to provide such documents.

6. Testing support. Conformance to memory model requirements is
difficult to test. We expect to work with engineers designing and
implementing tests with clear bases in specifications.

7. Tool support. The reformulated model will be amenable for use by
software development tools that analytically check for errors such as
race conditions, as well as those checking that security properties
hold across concurrent execution.  While design and construction of
tools themselves are out of scope, this JEP may contribute guidelines
for annotations that would enable high quality static and dynamic
analysis.


Risks and Assumptions
---------------------

Success requires contributions by concurrency experts in formal
specification, hardware and software engineering, and software
development tools.  We have pre-arranged a core of expertise by
obtaining tentative agreements to participate by academics,
researchers, and engineers with extensive experience and knowledge in
these areas.  We will continue to encourage other experts to
participate as well.

If successful, we expect that this effort may lead to various
enhancements, adjustments, and bugfixes across the platform. It is
also possible that some uncommon borderline programming constructions
will be shown to be problematic. However, we do not expect any further
impact on backwards compatibility, or on unrelated specifications or
APIs.

If this work fails to achieve its goals, then the current state of
affairs will continue to hold.

Dependences
-----------

The JEP does not depend on any others. We anticipate that
future JEPs related to concurrency will depend on this one.




From david.holmes at oracle.com  Wed Jan  8 21:41:18 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 09 Jan 2014 15:41:18 +1000
Subject: Printing the compiler thread when the process gets a SIGQUIT
In-Reply-To: <CAPYFHW25M84O+U1U=QYN+Ow9s8ga0gBpbY6-p=J-B8UgU87Oxw@mail.gmail.com>
References: <CAPYFHW25M84O+U1U=QYN+Ow9s8ga0gBpbY6-p=J-B8UgU87Oxw@mail.gmail.com>
Message-ID: <52CE367E.2060407@oracle.com>

Hi Jeremy,

On 9/01/2014 8:45 AM, Jeremy Manson wrote:
> Hi folks,
>
> We've found it useful to have a complete list of threads when we handle
> a SIGQUIT.  Hotspot currently prints out the VM thread and the GC
> threads, but not the compiler threads.  Follows a patch to make it do
> this.  Any interest, or was there a reason that compiler thread printing
> was never implemented?

I think you'd need to ask the compiler folk rather than runtime folk so 
cc'ing hotspot-dev to broaden the audience - and hopefully find a 
sponsor for this. :)

Looking at the patch you use:

  _name = NEW_C_HEAP_ARRAY(char, strlen(name) + 1, mtInternal);

whereas NamedThread uses:

_name = NEW_C_HEAP_ARRAY(char, max_name_len, mtThread);

I don't know whether mtInternal or mtThread is the appropriate selection 
here.

> (Not sure whether I should delete the associated memory or not...  There
> seems to be very little cleanup from compiler threads, or attempt to
> shut them down.)

I'd opt for doing the free in the destructor as NamedThread does.

Thanks,
David

> Jeremy

From magnus.ihse.bursie at oracle.com  Thu Jan  9 04:30:13 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 09 Jan 2014 13:30:13 +0100
Subject: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
In-Reply-To: <0603017D-7128-4EB0-9551-19979949ED78@oracle.com>
References: <ED9E1EFE-F980-4E66-8EAF-C12F180CF1F4@oracle.com>
	<52CD3D3B.9050002@oracle.com>
	<0603017D-7128-4EB0-9551-19979949ED78@oracle.com>
Message-ID: <52CE9655.8000506@oracle.com>

On 2014-01-08 22:11, Mike Duigou wrote:
> You are correct. Sorry (wrong -r option and use of a file list misled me into thinking it was generating the right content).
>
> I have added
>
>   http://cr.openjdk.java.net/~mduigou/JDK-8030350/3/webrev/
>
> and checked to make sure it has the right content.

Thanks!

A question regarding the changes in toolchain.m4:

> +      CCXXFLAGS_JDK="$CCXXFLAGS $CCXXFLAGS_JDK -Wall -Wextra -Wformat=2 -Wno-unused-parameter -Wno-unused -Wno-parentheses \

Isn't -Wno-unused-parameter redundant if you have -Wno-unused? I have 
not tested compiling code provoking that warning, but my understanding 
from reading http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html is 
that -Wno-unused will turn off all "unused" warnings. While 
unused-parameter is usually only just annoying, some of the other are 
more intelligent and useful, and could just as well be turned on -- but 
I understand if that is not part of your current fix.

Other than that, it looks good.

/Magnus

From mike.duigou at oracle.com  Thu Jan  9 09:08:56 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 9 Jan 2014 09:08:56 -0800
Subject: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
In-Reply-To: <52CE9655.8000506@oracle.com>
References: <ED9E1EFE-F980-4E66-8EAF-C12F180CF1F4@oracle.com>
	<52CD3D3B.9050002@oracle.com>
	<0603017D-7128-4EB0-9551-19979949ED78@oracle.com>
	<52CE9655.8000506@oracle.com>
Message-ID: <57E3EB12-04D6-46F8-AD6B-DCDD71B910A2@oracle.com>


On Jan 9 2014, at 04:30 , Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

> On 2014-01-08 22:11, Mike Duigou wrote:
>> You are correct. Sorry (wrong -r option and use of a file list misled me into thinking it was generating the right content).
>> 
>> I have added
>> 
>>  http://cr.openjdk.java.net/~mduigou/JDK-8030350/3/webrev/
>> 
>> and checked to make sure it has the right content.
> 
> Thanks!
> 
> A question regarding the changes in toolchain.m4:
> 
>> +      CCXXFLAGS_JDK="$CCXXFLAGS $CCXXFLAGS_JDK -Wall -Wextra -Wformat=2 -Wno-unused-parameter -Wno-unused -Wno-parentheses \
> 
> Isn't -Wno-unused-parameter redundant if you have -Wno-unused? I have not tested compiling code provoking that warning, but my understanding from reading http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html is that -Wno-unused will turn off all "unused" warnings. While unused-parameter is usually only just annoying, some of the other are more intelligent and useful, and could just as well be turned on -- but I understand if that is not part of your current fix.

For unknown reasons both seemed to be required. I am not sure why. Despite the -Wno-unused I still see many unused local warnings.

Mike

From jeremymanson at google.com  Thu Jan  9 10:01:30 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 9 Jan 2014 10:01:30 -0800
Subject: Printing the compiler thread when the process gets a SIGQUIT
In-Reply-To: <52CE367E.2060407@oracle.com>
References: <CAPYFHW25M84O+U1U=QYN+Ow9s8ga0gBpbY6-p=J-B8UgU87Oxw@mail.gmail.com>
	<52CE367E.2060407@oracle.com>
Message-ID: <CAPYFHW2h2yfMo9-_489n6DyYa74wNkdOZURcN8nQD5uNv_fuUg@mail.gmail.com>

On Wed, Jan 8, 2014 at 9:41 PM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Jeremy,
>
>
> On 9/01/2014 8:45 AM, Jeremy Manson wrote:
>
>> Hi folks,
>>
>> We've found it useful to have a complete list of threads when we handle
>> a SIGQUIT.  Hotspot currently prints out the VM thread and the GC
>> threads, but not the compiler threads.  Follows a patch to make it do
>> this.  Any interest, or was there a reason that compiler thread printing
>> was never implemented?
>>
>
> I think you'd need to ask the compiler folk rather than runtime folk so
> cc'ing hotspot-dev to broaden the audience - and hopefully find a sponsor
> for this. :)
>

Thanks.  I assumed it was a runtime / serviceability issue, but it being a
compiler issue also makes sense.

Basically, this is for users who get information (like CPU usage) about
threads from other sources, and are trying to figure out what those threads
do in the JVM.  They can do a SIGQUIT and find out about application
threads and VM threads and GC threads, but they then have these other,
leftover threads with no visibility.  This patch clarifies matters, and is
relatively straightforward, so it has been worthwhile having it.




> Looking at the patch you use:
>
>  _name = NEW_C_HEAP_ARRAY(char, strlen(name) + 1, mtInternal);
>
> whereas NamedThread uses:
>
> _name = NEW_C_HEAP_ARRAY(char, max_name_len, mtThread);
>
> I don't know whether mtInternal or mtThread is the appropriate selection
> here.
>

Presumably, the sponsor (or lack thereof) would know?

 (Not sure whether I should delete the associated memory or not...  There
>> seems to be very little cleanup from compiler threads, or attempt to
>> shut them down.)
>>
>
> I'd opt for doing the free in the destructor as NamedThread does.
>
>
That was my inclination, but CompilerThread doesn't have a destructor.
 It's also been my experience that CompilerThreads are never shut down
cleanly (JVMTI Compile events continue to be sent after JVM shutdown, which
has resulted in my removing a lot of cleanup code from my own code).

Anyway, I'll wait for someone else to chime in.  (I can send the patch
again, if people on hotspot-dev didn't get it the first time.)

Jeremy

From christian.thalinger at oracle.com  Thu Jan  9 10:45:57 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 9 Jan 2014 10:45:57 -0800
Subject: Printing the compiler thread when the process gets a SIGQUIT
In-Reply-To: <CAPYFHW2h2yfMo9-_489n6DyYa74wNkdOZURcN8nQD5uNv_fuUg@mail.gmail.com>
References: <CAPYFHW25M84O+U1U=QYN+Ow9s8ga0gBpbY6-p=J-B8UgU87Oxw@mail.gmail.com>
	<52CE367E.2060407@oracle.com>
	<CAPYFHW2h2yfMo9-_489n6DyYa74wNkdOZURcN8nQD5uNv_fuUg@mail.gmail.com>
Message-ID: <E49C46A0-EEDF-4786-AB2A-E58102F9FDBA@oracle.com>

[BCC?ing hotspot-runtime-dev]

On Jan 9, 2014, at 10:01 AM, Jeremy Manson <jeremymanson at google.com> wrote:

> On Wed, Jan 8, 2014 at 9:41 PM, David Holmes <david.holmes at oracle.com>wrote:
> 
>> Hi Jeremy,
>> 
>> 
>> On 9/01/2014 8:45 AM, Jeremy Manson wrote:
>> 
>>> Hi folks,
>>> 
>>> We've found it useful to have a complete list of threads when we handle
>>> a SIGQUIT.  Hotspot currently prints out the VM thread and the GC
>>> threads, but not the compiler threads.  Follows a patch to make it do
>>> this.  Any interest, or was there a reason that compiler thread printing
>>> was never implemented?

I?m confused.  Aren?t we already printing the compiler threads?

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fb9f5007000 nid=0x5403 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fb9f5006000 nid=0x5203 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

Compiler threads are Java threads:

class CompilerThread : public JavaThread {

so they use JavaThread::print_on.  Am I still missing something?

Although I agree that this output is misleading:

"VM Periodic Task Thread" os_prio=31 tid=0x00007fe39b00d800 nid=0x5803 waiting on condition 

Compiler thread printing unimplemented.

JNI global references: 109

Perhaps we should remove the CompileBroker printing logic.

>>> 
>> 
>> I think you'd need to ask the compiler folk rather than runtime folk so
>> cc'ing hotspot-dev to broaden the audience - and hopefully find a sponsor
>> for this. :)
>> 
> 
> Thanks.  I assumed it was a runtime / serviceability issue, but it being a
> compiler issue also makes sense.
> 
> Basically, this is for users who get information (like CPU usage) about
> threads from other sources, and are trying to figure out what those threads
> do in the JVM.  They can do a SIGQUIT and find out about application
> threads and VM threads and GC threads, but they then have these other,
> leftover threads with no visibility.  This patch clarifies matters, and is
> relatively straightforward, so it has been worthwhile having it.
> 
> 
> 
> 
>> Looking at the patch you use:
>> 
>> _name = NEW_C_HEAP_ARRAY(char, strlen(name) + 1, mtInternal);
>> 
>> whereas NamedThread uses:
>> 
>> _name = NEW_C_HEAP_ARRAY(char, max_name_len, mtThread);
>> 
>> I don't know whether mtInternal or mtThread is the appropriate selection
>> here.
>> 
> 
> Presumably, the sponsor (or lack thereof) would know?
> 
> (Not sure whether I should delete the associated memory or not...  There
>>> seems to be very little cleanup from compiler threads, or attempt to
>>> shut them down.)
>>> 
>> 
>> I'd opt for doing the free in the destructor as NamedThread does.
>> 
>> 
> That was my inclination, but CompilerThread doesn't have a destructor.
> It's also been my experience that CompilerThreads are never shut down
> cleanly (JVMTI Compile events continue to be sent after JVM shutdown, which
> has resulted in my removing a lot of cleanup code from my own code).
> 
> Anyway, I'll wait for someone else to chime in.  (I can send the patch
> again, if people on hotspot-dev didn't get it the first time.)
> 
> Jeremy


From jeremymanson at google.com  Thu Jan  9 13:39:55 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 9 Jan 2014 13:39:55 -0800
Subject: Printing the compiler thread when the process gets a SIGQUIT
In-Reply-To: <E49C46A0-EEDF-4786-AB2A-E58102F9FDBA@oracle.com>
References: <CAPYFHW25M84O+U1U=QYN+Ow9s8ga0gBpbY6-p=J-B8UgU87Oxw@mail.gmail.com>
	<52CE367E.2060407@oracle.com>
	<CAPYFHW2h2yfMo9-_489n6DyYa74wNkdOZURcN8nQD5uNv_fuUg@mail.gmail.com>
	<E49C46A0-EEDF-4786-AB2A-E58102F9FDBA@oracle.com>
Message-ID: <CAPYFHW2_SDZDL94m3A2yFs4w_O7Ry9QbDpppZe8sWaQ2nyS+FA@mail.gmail.com>

You are completely right!  This change is a few years old, and I sent it as
part of a plan to rid ourselves of patches I can offload on you guys.  What
was missing on my end was forgotten context.

So, I looked through my notes, and realized that this was part of a larger
change I did to make it possible to export a list of non-Java threads in
the JVM through a programmatic API.

Right now, if you want a complete list of threads, you basically can call
ThreadMXBean.dumpAllThreads for application threads, and you can cut a hole
in the JVM and call the SIGQUIT code for the native threads.  However, if
you do that, you don't get the compiler threads (because they aren't native
threads and they aren't returned with the MXBean).  So, this was part of a
subsequent attempt to be able to export only the compiler threads, and
won't help anything a stock VM does at all.

There were also subsequent bugfix patches I didn't add.  I think I need to
go away and rationalize all of that code.  If there is any interest in
providing an API to expose native/compiler thread info to users via an API
(an MXBean, maybe?), let me know, and I can send it in.

Jeremy


On Thu, Jan 9, 2014 at 10:45 AM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:

> [BCC?ing hotspot-runtime-dev]
>
> On Jan 9, 2014, at 10:01 AM, Jeremy Manson <jeremymanson at google.com>
> wrote:
>
> > On Wed, Jan 8, 2014 at 9:41 PM, David Holmes <david.holmes at oracle.com
> >wrote:
> >
> >> Hi Jeremy,
> >>
> >>
> >> On 9/01/2014 8:45 AM, Jeremy Manson wrote:
> >>
> >>> Hi folks,
> >>>
> >>> We've found it useful to have a complete list of threads when we handle
> >>> a SIGQUIT.  Hotspot currently prints out the VM thread and the GC
> >>> threads, but not the compiler threads.  Follows a patch to make it do
> >>> this.  Any interest, or was there a reason that compiler thread
> printing
> >>> was never implemented?
>
> I?m confused.  Aren?t we already printing the compiler threads?
>
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fb9f5007000
> nid=0x5403 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fb9f5006000
> nid=0x5203 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> Compiler threads are Java threads:
>
> class CompilerThread : public JavaThread {
>
> so they use JavaThread::print_on.  Am I still missing something?
>
> Although I agree that this output is misleading:
>
> "VM Periodic Task Thread" os_prio=31 tid=0x00007fe39b00d800 nid=0x5803
> waiting on condition
>
> Compiler thread printing unimplemented.
>
> JNI global references: 109
>
> Perhaps we should remove the CompileBroker printing logic.
>
> >>>
> >>
> >> I think you'd need to ask the compiler folk rather than runtime folk so
> >> cc'ing hotspot-dev to broaden the audience - and hopefully find a
> sponsor
> >> for this. :)
> >>
> >
> > Thanks.  I assumed it was a runtime / serviceability issue, but it being
> a
> > compiler issue also makes sense.
> >
> > Basically, this is for users who get information (like CPU usage) about
> > threads from other sources, and are trying to figure out what those
> threads
> > do in the JVM.  They can do a SIGQUIT and find out about application
> > threads and VM threads and GC threads, but they then have these other,
> > leftover threads with no visibility.  This patch clarifies matters, and
> is
> > relatively straightforward, so it has been worthwhile having it.
> >
> >
> >
> >
> >> Looking at the patch you use:
> >>
> >> _name = NEW_C_HEAP_ARRAY(char, strlen(name) + 1, mtInternal);
> >>
> >> whereas NamedThread uses:
> >>
> >> _name = NEW_C_HEAP_ARRAY(char, max_name_len, mtThread);
> >>
> >> I don't know whether mtInternal or mtThread is the appropriate selection
> >> here.
> >>
> >
> > Presumably, the sponsor (or lack thereof) would know?
> >
> > (Not sure whether I should delete the associated memory or not...  There
> >>> seems to be very little cleanup from compiler threads, or attempt to
> >>> shut them down.)
> >>>
> >>
> >> I'd opt for doing the free in the destructor as NamedThread does.
> >>
> >>
> > That was my inclination, but CompilerThread doesn't have a destructor.
> > It's also been my experience that CompilerThreads are never shut down
> > cleanly (JVMTI Compile events continue to be sent after JVM shutdown,
> which
> > has resulted in my removing a lot of cleanup code from my own code).
> >
> > Anyway, I'll wait for someone else to chime in.  (I can send the patch
> > again, if people on hotspot-dev didn't get it the first time.)
> >
> > Jeremy
>
>

From mandy.chung at oracle.com  Thu Jan  9 14:05:23 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 09 Jan 2014 14:05:23 -0800
Subject: Printing the compiler thread when the process gets a SIGQUIT
In-Reply-To: <CAPYFHW2_SDZDL94m3A2yFs4w_O7Ry9QbDpppZe8sWaQ2nyS+FA@mail.gmail.com>
References: <CAPYFHW25M84O+U1U=QYN+Ow9s8ga0gBpbY6-p=J-B8UgU87Oxw@mail.gmail.com>	<52CE367E.2060407@oracle.com>	<CAPYFHW2h2yfMo9-_489n6DyYa74wNkdOZURcN8nQD5uNv_fuUg@mail.gmail.com>	<E49C46A0-EEDF-4786-AB2A-E58102F9FDBA@oracle.com>
	<CAPYFHW2_SDZDL94m3A2yFs4w_O7Ry9QbDpppZe8sWaQ2nyS+FA@mail.gmail.com>
Message-ID: <52CF1D23.2020304@oracle.com>

JavaThreads that are hidden from external view 
(is_hidden_from_external_view()) are currently excluded from JVM TI and 
java.lang.management API to obtain thread dumps and other access/control 
(e.g. thread start event, suspend/resume etc).   I think it'd be useful 
to allow getting thread dumps of all Java threads including the hidden 
ones for troubleshooting.   I don't see any issue for 
java.lang.management to expose hidden threads since it only provides 
monitoring information.  However, that would be inconsistent with JVM TI 
which may be worth some spec clarification/update w.r.t. these hidden 
threads (implementation-specific threads).

My 2 cents.

Mandy

On 1/9/2014 1:39 PM, Jeremy Manson wrote:
> You are completely right!  This change is a few years old, and I sent it as
> part of a plan to rid ourselves of patches I can offload on you guys.  What
> was missing on my end was forgotten context.
>
> So, I looked through my notes, and realized that this was part of a larger
> change I did to make it possible to export a list of non-Java threads in
> the JVM through a programmatic API.
>
> Right now, if you want a complete list of threads, you basically can call
> ThreadMXBean.dumpAllThreads for application threads, and you can cut a hole
> in the JVM and call the SIGQUIT code for the native threads.  However, if
> you do that, you don't get the compiler threads (because they aren't native
> threads and they aren't returned with the MXBean).  So, this was part of a
> subsequent attempt to be able to export only the compiler threads, and
> won't help anything a stock VM does at all.
>
> There were also subsequent bugfix patches I didn't add.  I think I need to
> go away and rationalize all of that code.  If there is any interest in
> providing an API to expose native/compiler thread info to users via an API
> (an MXBean, maybe?), let me know, and I can send it in.
>
> Jeremy
>
>
> On Thu, Jan 9, 2014 at 10:45 AM, Christian Thalinger <
> christian.thalinger at oracle.com> wrote:
>
>> [BCC?ing hotspot-runtime-dev]
>>
>> On Jan 9, 2014, at 10:01 AM, Jeremy Manson <jeremymanson at google.com>
>> wrote:
>>
>>> On Wed, Jan 8, 2014 at 9:41 PM, David Holmes <david.holmes at oracle.com
>>> wrote:
>>>
>>>> Hi Jeremy,
>>>>
>>>>
>>>> On 9/01/2014 8:45 AM, Jeremy Manson wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> We've found it useful to have a complete list of threads when we handle
>>>>> a SIGQUIT.  Hotspot currently prints out the VM thread and the GC
>>>>> threads, but not the compiler threads.  Follows a patch to make it do
>>>>> this.  Any interest, or was there a reason that compiler thread
>> printing
>>>>> was never implemented?
>> I?m confused.  Aren?t we already printing the compiler threads?
>>
>> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fb9f5007000
>> nid=0x5403 waiting on condition [0x0000000000000000]
>>     java.lang.Thread.State: RUNNABLE
>>
>> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fb9f5006000
>> nid=0x5203 waiting on condition [0x0000000000000000]
>>     java.lang.Thread.State: RUNNABLE
>>
>> Compiler threads are Java threads:
>>
>> class CompilerThread : public JavaThread {
>>
>> so they use JavaThread::print_on.  Am I still missing something?
>>
>> Although I agree that this output is misleading:
>>
>> "VM Periodic Task Thread" os_prio=31 tid=0x00007fe39b00d800 nid=0x5803
>> waiting on condition
>>
>> Compiler thread printing unimplemented.
>>
>> JNI global references: 109
>>
>> Perhaps we should remove the CompileBroker printing logic.
>>
>>>> I think you'd need to ask the compiler folk rather than runtime folk so
>>>> cc'ing hotspot-dev to broaden the audience - and hopefully find a
>> sponsor
>>>> for this. :)
>>>>
>>> Thanks.  I assumed it was a runtime / serviceability issue, but it being
>> a
>>> compiler issue also makes sense.
>>>
>>> Basically, this is for users who get information (like CPU usage) about
>>> threads from other sources, and are trying to figure out what those
>> threads
>>> do in the JVM.  They can do a SIGQUIT and find out about application
>>> threads and VM threads and GC threads, but they then have these other,
>>> leftover threads with no visibility.  This patch clarifies matters, and
>> is
>>> relatively straightforward, so it has been worthwhile having it.
>>>
>>>
>>>
>>>
>>>> Looking at the patch you use:
>>>>
>>>> _name = NEW_C_HEAP_ARRAY(char, strlen(name) + 1, mtInternal);
>>>>
>>>> whereas NamedThread uses:
>>>>
>>>> _name = NEW_C_HEAP_ARRAY(char, max_name_len, mtThread);
>>>>
>>>> I don't know whether mtInternal or mtThread is the appropriate selection
>>>> here.
>>>>
>>> Presumably, the sponsor (or lack thereof) would know?
>>>
>>> (Not sure whether I should delete the associated memory or not...  There
>>>>> seems to be very little cleanup from compiler threads, or attempt to
>>>>> shut them down.)
>>>>>
>>>> I'd opt for doing the free in the destructor as NamedThread does.
>>>>
>>>>
>>> That was my inclination, but CompilerThread doesn't have a destructor.
>>> It's also been my experience that CompilerThreads are never shut down
>>> cleanly (JVMTI Compile events continue to be sent after JVM shutdown,
>> which
>>> has resulted in my removing a lot of cleanup code from my own code).
>>>
>>> Anyway, I'll wait for someone else to chime in.  (I can send the patch
>>> again, if people on hotspot-dev didn't get it the first time.)
>>>
>>> Jeremy
>>


From jesper.wilhelmsson at oracle.com  Fri Jan 10 04:49:17 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 10 Jan 2014 13:49:17 +0100
Subject: Changing lots of files - mainly GC code
Message-ID: <52CFEC4D.5000908@oracle.com>

Hi,

I have a change out for review that fixes a huge pile of typos in the comments 
in the GC code. The RFR was sent to the GC list, but I want to give a heads up 
in case anyone else is changing GC code and want to avoid merge conflicts.

The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/


There are also a few files where I happened to find a few typos "by accident" in 
code that is not strictly GC code. These are:

src/share/vm/memory/heap.cpp
src/share/vm/memory/heap.hpp
src/share/vm/memory/allocation.hpp
src/share/vm/memory/resourceArea.hpp
src/share/vm/runtime/thread.cpp

There is a total of eight typos fixed in these files so I think the risk of 
merge conflicts here is minimal. Are there any objections to including these 
fixes in the change?

Thanks,
/Jesper

From daniel.daugherty at oracle.com  Fri Jan 10 07:39:11 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 10 Jan 2014 08:39:11 -0700
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52CFEC4D.5000908@oracle.com>
References: <52CFEC4D.5000908@oracle.com>
Message-ID: <52D0141F.3070900@oracle.com>

On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
> Hi,
>
> I have a change out for review that fixes a huge pile of typos in the 
> comments in the GC code. The RFR was sent to the GC list, but I want 
> to give a heads up in case anyone else is changing GC code and want to 
> avoid merge conflicts.
>
> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>
>
> There are also a few files where I happened to find a few typos "by 
> accident" in code that is not strictly GC code. These are:
>
> src/share/vm/memory/heap.cpp
> src/share/vm/memory/heap.hpp
> src/share/vm/memory/allocation.hpp
> src/share/vm/memory/resourceArea.hpp
> src/share/vm/runtime/thread.cpp
>
> There is a total of eight typos fixed in these files so I think the 
> risk of merge conflicts here is minimal. Are there any objections to 
> including these fixes in the change?

Vote: go for it!

Dan

>
> Thanks,
> /Jesper


From coleen.phillimore at oracle.com  Fri Jan 10 07:54:54 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Fri, 10 Jan 2014 10:54:54 -0500
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D0141F.3070900@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
Message-ID: <52D017CE.6090509@oracle.com>

Seems fine with me also.  Could you find typos in the comments in the 
runtime code "by accident" too? :)
thanks,
Coleen

On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> I have a change out for review that fixes a huge pile of typos in the 
>> comments in the GC code. The RFR was sent to the GC list, but I want 
>> to give a heads up in case anyone else is changing GC code and want 
>> to avoid merge conflicts.
>>
>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>
>>
>> There are also a few files where I happened to find a few typos "by 
>> accident" in code that is not strictly GC code. These are:
>>
>> src/share/vm/memory/heap.cpp
>> src/share/vm/memory/heap.hpp
>> src/share/vm/memory/allocation.hpp
>> src/share/vm/memory/resourceArea.hpp
>> src/share/vm/runtime/thread.cpp
>>
>> There is a total of eight typos fixed in these files so I think the 
>> risk of merge conflicts here is minimal. Are there any objections to 
>> including these fixes in the change?
>
> Vote: go for it!
>
> Dan
>
>>
>> Thanks,
>> /Jesper
>


From harold.seigel at oracle.com  Fri Jan 10 09:56:00 2014
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Fri, 10 Jan 2014 17:56:00 +0000
Subject: hg: hsx/hotspot-main/hotspot: 8031059: invokestatic: ICCE trying to
	invoke static method when it clashes with an abstract method
	inherited from an interface
Message-ID: <20140110175602.85A1A624D2@hg.openjdk.java.net>

Changeset: c3f3cfd39184
Author:    hseigel
Date:      2014-01-10 12:11 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c3f3cfd39184

8031059: invokestatic: ICCE trying to invoke static method when it clashes with an abstract method inherited from an interface
Summary: Do not create AME overpass if there is a matching static method
Reviewed-by: lfoltan, coleenp, kamg

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


From rednaxelafx at gmail.com  Fri Jan 10 10:17:18 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Sat, 11 Jan 2014 02:17:18 +0800
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D017CE.6090509@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com>
Message-ID: <CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>

Hi Jesper,

Nice to see cleaner code!

Hitchhike: It'd be nice if you could include this typo in:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html
I didn't really like sending one-liner comment typo fix anyway...with a lot
of other typos, the story is different ;-)

Thanks,
Kris



On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore <
coleen.phillimore at oracle.com> wrote:

> Seems fine with me also.  Could you find typos in the comments in the
> runtime code "by accident" too? :)
> thanks,
> Coleen
>
>
> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>
>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>
>>> Hi,
>>>
>>> I have a change out for review that fixes a huge pile of typos in the
>>> comments in the GC code. The RFR was sent to the GC list, but I want to
>>> give a heads up in case anyone else is changing GC code and want to avoid
>>> merge conflicts.
>>>
>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>
>>>
>>> There are also a few files where I happened to find a few typos "by
>>> accident" in code that is not strictly GC code. These are:
>>>
>>> src/share/vm/memory/heap.cpp
>>> src/share/vm/memory/heap.hpp
>>> src/share/vm/memory/allocation.hpp
>>> src/share/vm/memory/resourceArea.hpp
>>> src/share/vm/runtime/thread.cpp
>>>
>>> There is a total of eight typos fixed in these files so I think the risk
>>> of merge conflicts here is minimal. Are there any objections to including
>>> these fixes in the change?
>>>
>>
>> Vote: go for it!
>>
>> Dan
>>
>>
>>> Thanks,
>>> /Jesper
>>>
>>
>>
>

From zhengyu.gu at oracle.com  Fri Jan 10 10:54:49 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 10 Jan 2014 13:54:49 -0500
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
Message-ID: <52D041F9.5070904@oracle.com>

The test was disabled due to JDK-8028095,  which is a dup of 
JDK-8020675. The problem has been fixed, this test should be re-enabled.

Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ 
<http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>

Thanks,

-Zhengyu

From john.coomes at oracle.com  Fri Jan 10 12:32:17 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:32:17 +0000
Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b123 for changeset
	1ecd4619f60c
Message-ID: <20140110203221.DD58A624DC@hg.openjdk.java.net>

Changeset: afecd2878aee
Author:    katleman
Date:      2014-01-10 08:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/afecd2878aee

Added tag jdk8-b123 for changeset 1ecd4619f60c

! .hgtags


From john.coomes at oracle.com  Fri Jan 10 12:32:26 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:32:26 +0000
Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b123 for changeset
	4e35b5b6d2e5
Message-ID: <20140110203239.A32C7624DD@hg.openjdk.java.net>

Changeset: 1a28f773c894
Author:    katleman
Date:      2014-01-10 08:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/1a28f773c894

Added tag jdk8-b123 for changeset 4e35b5b6d2e5

! .hgtags


From john.coomes at oracle.com  Fri Jan 10 12:32:45 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:32:45 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b123 for changeset
	91f5c542ccad
Message-ID: <20140110203255.731AE624DE@hg.openjdk.java.net>

Changeset: 241e4effed6d
Author:    katleman
Date:      2014-01-10 08:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/241e4effed6d

Added tag jdk8-b123 for changeset 91f5c542ccad

! .hgtags


From john.coomes at oracle.com  Fri Jan 10 12:32:13 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:32:13 +0000
Subject: hg: hsx/hotspot-main: Added tag jdk8-b123 for changeset ff1478785e43
Message-ID: <20140110203213.BEA09624DB@hg.openjdk.java.net>

Changeset: c330fa67c4da
Author:    katleman
Date:      2014-01-10 08:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/c330fa67c4da

Added tag jdk8-b123 for changeset ff1478785e43

! .hgtags


From john.coomes at oracle.com  Fri Jan 10 12:33:07 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:33:07 +0000
Subject: hg: hsx/hotspot-main/jdk: 2 new changesets
Message-ID: <20140110203504.3F449624DF@hg.openjdk.java.net>

Changeset: 484e16c0a040
Author:    nikgor
Date:      2014-01-07 12:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/484e16c0a040

8004562: Better support for crossdomain.xml
Reviewed-by: herrick, ngthomas, chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 13b28cffa140
Author:    katleman
Date:      2014-01-10 08:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13b28cffa140

Added tag jdk8-b123 for changeset 484e16c0a040

! .hgtags


From john.coomes at oracle.com  Fri Jan 10 12:37:27 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:37:27 +0000
Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b123 for changeset
	688f4167f921
Message-ID: <20140110203733.3B676624E1@hg.openjdk.java.net>

Changeset: 0b4301c79225
Author:    katleman
Date:      2014-01-10 08:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0b4301c79225

Added tag jdk8-b123 for changeset 688f4167f921

! .hgtags


From john.coomes at oracle.com  Fri Jan 10 12:37:04 2014
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Jan 2014 20:37:04 +0000
Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b123 for changeset
	a345cf28faca
Message-ID: <20140110203721.01268624E0@hg.openjdk.java.net>

Changeset: d5aab8300d3b
Author:    katleman
Date:      2014-01-10 08:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d5aab8300d3b

Added tag jdk8-b123 for changeset a345cf28faca

! .hgtags


From calvin.cheung at oracle.com  Fri Jan 10 13:00:22 2014
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 10 Jan 2014 13:00:22 -0800
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
In-Reply-To: <52D041F9.5070904@oracle.com>
References: <52D041F9.5070904@oracle.com>
Message-ID: <52D05F66.4020606@oracle.com>

Looks good to me.
Was it a test harness issue which got fixed?

Calvin

On 1/10/2014 10:54 AM, Zhengyu Gu wrote:
> The test was disabled due to JDK-8028095,  which is a dup of 
> JDK-8020675. The problem has been fixed, this test should be re-enabled.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
> Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>
>
> Thanks,
>
> -Zhengyu


From zhengyu.gu at oracle.com  Fri Jan 10 13:06:41 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 10 Jan 2014 16:06:41 -0500
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
In-Reply-To: <52D05F66.4020606@oracle.com>
References: <52D041F9.5070904@oracle.com> <52D05F66.4020606@oracle.com>
Message-ID: <52D060E1.3000705@oracle.com>

Thanks for the the review.

On 1/10/2014 4:00 PM, Calvin Cheung wrote:
> Looks good to me.
> Was it a test harness issue which got fixed?
>
The bug (8028095) that caused this test to be disabled, already fixed by 
8028095 <https://bugs.openjdk.java.net/browse/JDK-8028095> (by you :-)).

Thanks,

-Zhengyu

> Calvin )
>
> On 1/10/2014 10:54 AM, Zhengyu Gu wrote:
>> The test was disabled due to JDK-8028095, which is a dup of 
>> JDK-8020675. The problem has been fixed, this test should be re-enabled.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
>> Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>
>>
>> Thanks,
>>
>> -Zhengyu
>


From staffan.larsen at oracle.com  Mon Jan 13 01:10:38 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 13 Jan 2014 10:10:38 +0100
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
In-Reply-To: <52D041F9.5070904@oracle.com>
References: <52D041F9.5070904@oracle.com>
Message-ID: <268CA847-81C0-4E2F-8BAB-8FE1F17BEE4C@oracle.com>

Looks good!

Thanks,
/Staffan

On 10 jan 2014, at 19:54, Zhengyu Gu <zhengyu.gu at oracle.com> wrote:

> The test was disabled due to JDK-8028095,  which is a dup of JDK-8020675. The problem has been fixed, this test should be re-enabled.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
> Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ <http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>
> 
> Thanks,
> 
> -Zhengyu


From jesper.wilhelmsson at oracle.com  Mon Jan 13 05:07:26 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 13 Jan 2014 14:07:26 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>
References: <52CFEC4D.5000908@oracle.com>	<52D0141F.3070900@oracle.com>	<52D017CE.6090509@oracle.com>
	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>
Message-ID: <52D3E50E.5040308@oracle.com>

Hi Kris!

No problem, I'll add it to the change. Please verify that it looks OK in the 
updated webrev (same link as before).

http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/

/Jesper


Krystal Mok skrev 10/1/14 7:17 PM:
> Hi Jesper,
>
> Nice to see cleaner code!
>
> Hitchhike: It'd be nice if you could include this typo in:
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html
> I didn't really like sending one-liner comment typo fix anyway...with a lot of
> other typos, the story is different ;-)
>
> Thanks,
> Kris
>
>
>
> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore <coleen.phillimore at oracle.com
> <mailto:coleen.phillimore at oracle.com>> wrote:
>
>     Seems fine with me also.  Could you find typos in the comments in the
>     runtime code "by accident" too? :)
>     thanks,
>     Coleen
>
>
>     On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>
>         On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>
>             Hi,
>
>             I have a change out for review that fixes a huge pile of typos in
>             the comments in the GC code. The RFR was sent to the GC list, but I
>             want to give a heads up in case anyone else is changing GC code and
>             want to avoid merge conflicts.
>
>             The patch: http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>             <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>
>
>
>             There are also a few files where I happened to find a few typos "by
>             accident" in code that is not strictly GC code. These are:
>
>             src/share/vm/memory/heap.cpp
>             src/share/vm/memory/heap.hpp
>             src/share/vm/memory/__allocation.hpp
>             src/share/vm/memory/__resourceArea.hpp
>             src/share/vm/runtime/thread.__cpp
>
>             There is a total of eight typos fixed in these files so I think the
>             risk of merge conflicts here is minimal. Are there any objections to
>             including these fixes in the change?
>
>
>         Vote: go for it!
>
>         Dan
>
>
>             Thanks,
>             /Jesper
>
>
>
>

From jesper.wilhelmsson at oracle.com  Mon Jan 13 05:13:11 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 13 Jan 2014 14:13:11 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D017CE.6090509@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com>
Message-ID: <52D3E667.5080807@oracle.com>

Hi Coleen!

I accidentally browsed the runtime directory this weekend and found about 70 
typos. I have updated the webrev to include these.

Do you want me to push them as part of the GC-fix? (If so, please review the 
runtime-part of the change ;-) )
/Jesper


Coleen Phillmore skrev 10/1/14 4:54 PM:
> Seems fine with me also.  Could you find typos in the comments in the runtime
> code "by accident" too? :)
> thanks,
> Coleen
>
> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> I have a change out for review that fixes a huge pile of typos in the
>>> comments in the GC code. The RFR was sent to the GC list, but I want to give
>>> a heads up in case anyone else is changing GC code and want to avoid merge
>>> conflicts.
>>>
>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>
>>>
>>> There are also a few files where I happened to find a few typos "by accident"
>>> in code that is not strictly GC code. These are:
>>>
>>> src/share/vm/memory/heap.cpp
>>> src/share/vm/memory/heap.hpp
>>> src/share/vm/memory/allocation.hpp
>>> src/share/vm/memory/resourceArea.hpp
>>> src/share/vm/runtime/thread.cpp
>>>
>>> There is a total of eight typos fixed in these files so I think the risk of
>>> merge conflicts here is minimal. Are there any objections to including these
>>> fixes in the change?
>>
>> Vote: go for it!
>>
>> Dan
>>
>>>
>>> Thanks,
>>> /Jesper
>>
>

From coleen.phillimore at oracle.com  Mon Jan 13 05:44:16 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Mon, 13 Jan 2014 08:44:16 -0500
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D3E667.5080807@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com> <52D3E667.5080807@oracle.com>
Message-ID: <52D3EDB0.7010601@oracle.com>


Hi Jesper,
The runtime changes look great, thanks!   I suggest pushing them all 
together in hs-gc so there's a single changeset.  I don't see any merge 
difficulty with these changes.
Thanks!
Coleen

On 1/13/2014 8:13 AM, Jesper Wilhelmsson wrote:
> Hi Coleen!
>
> I accidentally browsed the runtime directory this weekend and found 
> about 70 typos. I have updated the webrev to include these.
>
> Do you want me to push them as part of the GC-fix? (If so, please 
> review the runtime-part of the change ;-) )
> /Jesper
>
>
> Coleen Phillmore skrev 10/1/14 4:54 PM:
>> Seems fine with me also.  Could you find typos in the comments in the 
>> runtime
>> code "by accident" too? :)
>> thanks,
>> Coleen
>>
>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> I have a change out for review that fixes a huge pile of typos in the
>>>> comments in the GC code. The RFR was sent to the GC list, but I 
>>>> want to give
>>>> a heads up in case anyone else is changing GC code and want to 
>>>> avoid merge
>>>> conflicts.
>>>>
>>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>>
>>>>
>>>> There are also a few files where I happened to find a few typos "by 
>>>> accident"
>>>> in code that is not strictly GC code. These are:
>>>>
>>>> src/share/vm/memory/heap.cpp
>>>> src/share/vm/memory/heap.hpp
>>>> src/share/vm/memory/allocation.hpp
>>>> src/share/vm/memory/resourceArea.hpp
>>>> src/share/vm/runtime/thread.cpp
>>>>
>>>> There is a total of eight typos fixed in these files so I think the 
>>>> risk of
>>>> merge conflicts here is minimal. Are there any objections to 
>>>> including these
>>>> fixes in the change?
>>>
>>> Vote: go for it!
>>>
>>> Dan
>>>
>>>>
>>>> Thanks,
>>>> /Jesper
>>>
>>


From zhengyu.gu at oracle.com  Mon Jan 13 05:40:04 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 13 Jan 2014 08:40:04 -0500
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
In-Reply-To: <268CA847-81C0-4E2F-8BAB-8FE1F17BEE4C@oracle.com>
References: <52D041F9.5070904@oracle.com>
	<268CA847-81C0-4E2F-8BAB-8FE1F17BEE4C@oracle.com>
Message-ID: <F42008B6-63D1-48AC-96BD-9759AA6CBC49@oracle.com>

Thanks for the review.

-Zhengyu

On Jan 13, 2014, at 4:10 AM, Staffan Larsen wrote:

> Looks good!
> 
> Thanks,
> /Staffan
> 
> On 10 jan 2014, at 19:54, Zhengyu Gu <zhengyu.gu at oracle.com> wrote:
> 
>> The test was disabled due to JDK-8028095,  which is a dup of JDK-8020675. The problem has been fixed, this test should be re-enabled.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
>> Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ <http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>
>> 
>> Thanks,
>> 
>> -Zhengyu
> 


From staffan.larsen at oracle.com  Mon Jan 13 06:12:21 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 13 Jan 2014 15:12:21 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D3EDB0.7010601@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com> <52D3E667.5080807@oracle.com>
	<52D3EDB0.7010601@oracle.com>
Message-ID: <977AFC4B-CCB9-4707-B2F4-8EFC28E7BDEB@oracle.com>

+1 - thanks for fixing this!

/Staffan

On 13 jan 2014, at 14:44, Coleen Phillmore <coleen.phillimore at oracle.com> wrote:

> 
> Hi Jesper,
> The runtime changes look great, thanks!   I suggest pushing them all together in hs-gc so there's a single changeset.  I don't see any merge difficulty with these changes.
> Thanks!
> Coleen
> 
> On 1/13/2014 8:13 AM, Jesper Wilhelmsson wrote:
>> Hi Coleen!
>> 
>> I accidentally browsed the runtime directory this weekend and found about 70 typos. I have updated the webrev to include these.
>> 
>> Do you want me to push them as part of the GC-fix? (If so, please review the runtime-part of the change ;-) )
>> /Jesper
>> 
>> 
>> Coleen Phillmore skrev 10/1/14 4:54 PM:
>>> Seems fine with me also.  Could you find typos in the comments in the runtime
>>> code "by accident" too? :)
>>> thanks,
>>> Coleen
>>> 
>>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>> 
>>>>> I have a change out for review that fixes a huge pile of typos in the
>>>>> comments in the GC code. The RFR was sent to the GC list, but I want to give
>>>>> a heads up in case anyone else is changing GC code and want to avoid merge
>>>>> conflicts.
>>>>> 
>>>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>>> 
>>>>> 
>>>>> There are also a few files where I happened to find a few typos "by accident"
>>>>> in code that is not strictly GC code. These are:
>>>>> 
>>>>> src/share/vm/memory/heap.cpp
>>>>> src/share/vm/memory/heap.hpp
>>>>> src/share/vm/memory/allocation.hpp
>>>>> src/share/vm/memory/resourceArea.hpp
>>>>> src/share/vm/runtime/thread.cpp
>>>>> 
>>>>> There is a total of eight typos fixed in these files so I think the risk of
>>>>> merge conflicts here is minimal. Are there any objections to including these
>>>>> fixes in the change?
>>>> 
>>>> Vote: go for it!
>>>> 
>>>> Dan
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> /Jesper
>>>> 
>>> 
> 


From coleen.phillimore at oracle.com  Mon Jan 13 07:40:07 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Mon, 13 Jan 2014 10:40:07 -0500
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
In-Reply-To: <F42008B6-63D1-48AC-96BD-9759AA6CBC49@oracle.com>
References: <52D041F9.5070904@oracle.com>	<268CA847-81C0-4E2F-8BAB-8FE1F17BEE4C@oracle.com>
	<F42008B6-63D1-48AC-96BD-9759AA6CBC49@oracle.com>
Message-ID: <52D408D7.50504@oracle.com>


Looks good.
Coleen

On 1/13/2014 8:40 AM, Zhengyu Gu wrote:
> Thanks for the review.
>
> -Zhengyu
>
> On Jan 13, 2014, at 4:10 AM, Staffan Larsen wrote:
>
>> Looks good!
>>
>> Thanks,
>> /Staffan
>>
>> On 10 jan 2014, at 19:54, Zhengyu Gu <zhengyu.gu at oracle.com> wrote:
>>
>>> The test was disabled due to JDK-8028095,  which is a dup of JDK-8020675. The problem has been fixed, this test should be re-enabled.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
>>> Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ <http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>
>>>
>>> Thanks,
>>>
>>> -Zhengyu


From jesper.wilhelmsson at oracle.com  Mon Jan 13 09:04:54 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 13 Jan 2014 18:04:54 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D3EDB0.7010601@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com> <52D3E667.5080807@oracle.com>
	<52D3EDB0.7010601@oracle.com>
Message-ID: <52D41CB6.4040701@oracle.com>

Coleen,

Thanks for the review!

When looking at the runtime code I also found a ResourceMark rm; on line 841 in 
safepoint.cpp that seems unused. I won't remove it in the typos fix and I don't 
edit the safepoint code on a regular basis. Maybe you (or someone else) have 
related changes where it makes sense to remove it?
/Jesper


Coleen Phillmore skrev 13/1/14 2:44 PM:
>
> Hi Jesper,
> The runtime changes look great, thanks!   I suggest pushing them all together in
> hs-gc so there's a single changeset.  I don't see any merge difficulty with
> these changes.
> Thanks!
> Coleen
>
> On 1/13/2014 8:13 AM, Jesper Wilhelmsson wrote:
>> Hi Coleen!
>>
>> I accidentally browsed the runtime directory this weekend and found about 70
>> typos. I have updated the webrev to include these.
>>
>> Do you want me to push them as part of the GC-fix? (If so, please review the
>> runtime-part of the change ;-) )
>> /Jesper
>>
>>
>> Coleen Phillmore skrev 10/1/14 4:54 PM:
>>> Seems fine with me also.  Could you find typos in the comments in the runtime
>>> code "by accident" too? :)
>>> thanks,
>>> Coleen
>>>
>>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> I have a change out for review that fixes a huge pile of typos in the
>>>>> comments in the GC code. The RFR was sent to the GC list, but I want to give
>>>>> a heads up in case anyone else is changing GC code and want to avoid merge
>>>>> conflicts.
>>>>>
>>>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>>>
>>>>>
>>>>> There are also a few files where I happened to find a few typos "by accident"
>>>>> in code that is not strictly GC code. These are:
>>>>>
>>>>> src/share/vm/memory/heap.cpp
>>>>> src/share/vm/memory/heap.hpp
>>>>> src/share/vm/memory/allocation.hpp
>>>>> src/share/vm/memory/resourceArea.hpp
>>>>> src/share/vm/runtime/thread.cpp
>>>>>
>>>>> There is a total of eight typos fixed in these files so I think the risk of
>>>>> merge conflicts here is minimal. Are there any objections to including these
>>>>> fixes in the change?
>>>>
>>>> Vote: go for it!
>>>>
>>>> Dan
>>>>
>>>>>
>>>>> Thanks,
>>>>> /Jesper
>>>>
>>>
>

From coleen.phillimore at oracle.com  Mon Jan 13 09:23:23 2014
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Mon, 13 Jan 2014 12:23:23 -0500
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D41CB6.4040701@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com> <52D3E667.5080807@oracle.com>
	<52D3EDB0.7010601@oracle.com> <52D41CB6.4040701@oracle.com>
Message-ID: <52D4210B.3010404@oracle.com>


On 1/13/2014 12:04 PM, Jesper Wilhelmsson wrote:
> Coleen,
>
> Thanks for the review!
>
> When looking at the runtime code I also found a ResourceMark rm; on 
> line 841 in safepoint.cpp that seems unused. I won't remove it in the 
> typos fix and I don't edit the safepoint code on a regular basis. 
> Maybe you (or someone else) have related changes where it makes sense 
> to remove it?

Does any compiler complain about it being unused?  If so, it would be an 
error for the compiler.   "rm" is a scoped object.  The ResourceMark 
constructor sets a mark in the resource area of the thread, and the 
destructor of ResourceMark resets the mark.  It's for thread local 
allocation.   So it is used and shouldn't be removed.   HandleMark, 
MutexLocker are other similar scoped objects.

Thanks,
Coleen

> /Jesper
>
>
> Coleen Phillmore skrev 13/1/14 2:44 PM:
>>
>> Hi Jesper,
>> The runtime changes look great, thanks!   I suggest pushing them all 
>> together in
>> hs-gc so there's a single changeset.  I don't see any merge 
>> difficulty with
>> these changes.
>> Thanks!
>> Coleen
>>
>> On 1/13/2014 8:13 AM, Jesper Wilhelmsson wrote:
>>> Hi Coleen!
>>>
>>> I accidentally browsed the runtime directory this weekend and found 
>>> about 70
>>> typos. I have updated the webrev to include these.
>>>
>>> Do you want me to push them as part of the GC-fix? (If so, please 
>>> review the
>>> runtime-part of the change ;-) )
>>> /Jesper
>>>
>>>
>>> Coleen Phillmore skrev 10/1/14 4:54 PM:
>>>> Seems fine with me also.  Could you find typos in the comments in 
>>>> the runtime
>>>> code "by accident" too? :)
>>>> thanks,
>>>> Coleen
>>>>
>>>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have a change out for review that fixes a huge pile of typos in 
>>>>>> the
>>>>>> comments in the GC code. The RFR was sent to the GC list, but I 
>>>>>> want to give
>>>>>> a heads up in case anyone else is changing GC code and want to 
>>>>>> avoid merge
>>>>>> conflicts.
>>>>>>
>>>>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>>>>
>>>>>>
>>>>>> There are also a few files where I happened to find a few typos 
>>>>>> "by accident"
>>>>>> in code that is not strictly GC code. These are:
>>>>>>
>>>>>> src/share/vm/memory/heap.cpp
>>>>>> src/share/vm/memory/heap.hpp
>>>>>> src/share/vm/memory/allocation.hpp
>>>>>> src/share/vm/memory/resourceArea.hpp
>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>
>>>>>> There is a total of eight typos fixed in these files so I think 
>>>>>> the risk of
>>>>>> merge conflicts here is minimal. Are there any objections to 
>>>>>> including these
>>>>>> fixes in the change?
>>>>>
>>>>> Vote: go for it!
>>>>>
>>>>> Dan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> /Jesper
>>>>>
>>>>
>>


From rednaxelafx at gmail.com  Mon Jan 13 10:36:53 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Tue, 14 Jan 2014 02:36:53 +0800
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D3E50E.5040308@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com>
	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>
	<52D3E50E.5040308@oracle.com>
Message-ID: <CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>

Hi Jesper,

Thanks! I took a look and the change was fine.

I do have a couple of other comment fixes that I'd like to hitchhike:

1. oops/method.hpp

The comments say ConstMethod* and MethodData* are oops, which they aren't
anymore.
I'm not sure if the wording for "putting oops and method_size first for
better gc cache locality" still matters. It probably doesn't matter
anymore, since GC doesn't have to mark through these fields with the
PermGen removal.

2. ci/ciField.hpp, ci/ciField.cpp

The comments say in order to consider a field as a constant, it cannot hold
an non-perm-space oop. I believe this limitation has been removed. Could
someone from the compiler team verify if that's true?

The diff is at the end of this mail.

Thanks,
Kris

diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
--- a/src/share/vm/ci/ciField.cpp Fri Dec 27 07:51:07 2013 -0800
+++ b/src/share/vm/ci/ciField.cpp Mon Jan 13 10:31:17 2014 -0800
@@ -202,13 +202,9 @@
     }

     // This field just may be constant.  The only cases where it will
-    // not be constant are:
+    // not be constant is:
     //
-    // 1. The field holds a non-perm-space oop.  The field is, strictly
-    //    speaking, constant but we cannot embed non-perm-space oops into
-    //    generated code.  For the time being we need to consider the
-    //    field to be not constant.
-    // 2. The field is a *special* static&final field whose value
+    // 1. The field is a *special* static&final field whose value
     //    may change.  The three examples are java.lang.System.in,
     //    java.lang.System.out, and java.lang.System.err.

diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
--- a/src/share/vm/ci/ciField.hpp Fri Dec 27 07:51:07 2013 -0800
+++ b/src/share/vm/ci/ciField.hpp Mon Jan 13 10:31:17 2014 -0800
@@ -130,9 +130,7 @@
   //   1. The field is both static and final
   //   2. The canonical holder of the field has undergone
   //      static initialization.
-  //   3. If the field is an object or array, then the oop
-  //      in question is allocated in perm space.
-  //   4. The field is not one of the special static/final
+  //   3. The field is not one of the special static/final
   //      non-constant fields.  These are java.lang.System.in
   //      and java.lang.System.out.  Abomination.
   //
diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
--- a/src/share/vm/oops/method.hpp Fri Dec 27 07:51:07 2013 -0800
+++ b/src/share/vm/oops/method.hpp Mon Jan 13 10:31:17 2014 -0800
@@ -38,13 +38,11 @@
 #include "utilities/accessFlags.hpp"
 #include "utilities/growableArray.hpp"

-// A Method* represents a Java method.
+// A Method represents a Java method.
 //
 // Memory layout (each line represents a word). Note that most
applications load thousands of methods,
 // so keeping the size of this structure small has a big impact on
footprint.
 //
-// We put all oops and method_size first for better gc cache locality.
-//
 // The actual bytecodes are inlined after the end of the Method struct.
 //
 // There are bits in the access_flags telling whether inlined tables are
present.
@@ -64,17 +62,17 @@
 // | header                                               |
 // | klass                                                |
 // |------------------------------------------------------|
-// | ConstMethod*                   (oop)                 |
+// | ConstMethod*                   (metadata)            |
 // |------------------------------------------------------|
-// | methodData                     (oop)                 |
-// | methodCounters                                       |
+// | MethodData*                    (metadata)            |
+// | MethodCounters                                       |
 // |------------------------------------------------------|
 // | access_flags                                         |
 // | vtable_index                                         |
 // |------------------------------------------------------|
 // | result_index (C++ interpreter only)                  |
 // |------------------------------------------------------|
-// | method_size             |   intrinsic_id|   flags    |
+// | method_size             | intrinsic_id  |   flags    |
 // |------------------------------------------------------|
 // | code                           (pointer)             |
 // | i2i                            (pointer)             |




On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson <
jesper.wilhelmsson at oracle.com> wrote:

> Hi Kris!
>
> No problem, I'll add it to the change. Please verify that it looks OK in
> the updated webrev (same link as before).
>
> http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>
> /Jesper
>
>
> Krystal Mok skrev 10/1/14 7:17 PM:
>
>> Hi Jesper,
>>
>> Nice to see cleaner code!
>>
>> Hitchhike: It'd be nice if you could include this typo in:
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-
>> dev/2014-January/012944.html
>> I didn't really like sending one-liner comment typo fix anyway...with a
>> lot of
>> other typos, the story is different ;-)
>>
>> Thanks,
>> Kris
>>
>>
>>
>> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore <
>> coleen.phillimore at oracle.com
>> <mailto:coleen.phillimore at oracle.com>> wrote:
>>
>>     Seems fine with me also.  Could you find typos in the comments in the
>>     runtime code "by accident" too? :)
>>     thanks,
>>     Coleen
>>
>>
>>     On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>
>>         On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>
>>             Hi,
>>
>>             I have a change out for review that fixes a huge pile of
>> typos in
>>             the comments in the GC code. The RFR was sent to the GC list,
>> but I
>>             want to give a heads up in case anyone else is changing GC
>> code and
>>             want to avoid merge conflicts.
>>
>>             The patch: http://cr.openjdk.java.net/~__
>> jwilhelm/8025856/webrev.1/
>>
>>             <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>
>>
>>
>>             There are also a few files where I happened to find a few
>> typos "by
>>             accident" in code that is not strictly GC code. These are:
>>
>>             src/share/vm/memory/heap.cpp
>>             src/share/vm/memory/heap.hpp
>>             src/share/vm/memory/__allocation.hpp
>>             src/share/vm/memory/__resourceArea.hpp
>>             src/share/vm/runtime/thread.__cpp
>>
>>
>>             There is a total of eight typos fixed in these files so I
>> think the
>>             risk of merge conflicts here is minimal. Are there any
>> objections to
>>             including these fixes in the change?
>>
>>
>>         Vote: go for it!
>>
>>         Dan
>>
>>
>>             Thanks,
>>             /Jesper
>>
>>
>>
>>
>>

From jesper.wilhelmsson at oracle.com  Mon Jan 13 09:59:28 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 13 Jan 2014 18:59:28 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D4210B.3010404@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com> <52D3E667.5080807@oracle.com>
	<52D3EDB0.7010601@oracle.com> <52D41CB6.4040701@oracle.com>
	<52D4210B.3010404@oracle.com>
Message-ID: <52D42980.5050801@oracle.com>

Coleen Phillmore skrev 13/1/14 6:23 PM:
>
> On 1/13/2014 12:04 PM, Jesper Wilhelmsson wrote:
>> Coleen,
>>
>> Thanks for the review!
>>
>> When looking at the runtime code I also found a ResourceMark rm; on line 841
>> in safepoint.cpp that seems unused. I won't remove it in the typos fix and I
>> don't edit the safepoint code on a regular basis. Maybe you (or someone else)
>> have related changes where it makes sense to remove it?
>
> Does any compiler complain about it being unused?  If so, it would be an error
> for the compiler.

The Solaris Studio IDE marks the variable rm as unused. I guess it only sees 
that it isn't directly used in the code nearby. Side effects like the ones you 
describe are probably hard to figure out for the IDE.

Thanks,
/Jesper

> "rm" is a scoped object.  The ResourceMark constructor sets
> a mark in the resource area of the thread, and the destructor of ResourceMark
> resets the mark.  It's for thread local allocation.   So it is used and
> shouldn't be removed.   HandleMark, MutexLocker are other similar scoped objects.
>
> Thanks,
> Coleen
>
>> /Jesper
>>
>>
>> Coleen Phillmore skrev 13/1/14 2:44 PM:
>>>
>>> Hi Jesper,
>>> The runtime changes look great, thanks!   I suggest pushing them all together in
>>> hs-gc so there's a single changeset.  I don't see any merge difficulty with
>>> these changes.
>>> Thanks!
>>> Coleen
>>>
>>> On 1/13/2014 8:13 AM, Jesper Wilhelmsson wrote:
>>>> Hi Coleen!
>>>>
>>>> I accidentally browsed the runtime directory this weekend and found about 70
>>>> typos. I have updated the webrev to include these.
>>>>
>>>> Do you want me to push them as part of the GC-fix? (If so, please review the
>>>> runtime-part of the change ;-) )
>>>> /Jesper
>>>>
>>>>
>>>> Coleen Phillmore skrev 10/1/14 4:54 PM:
>>>>> Seems fine with me also.  Could you find typos in the comments in the runtime
>>>>> code "by accident" too? :)
>>>>> thanks,
>>>>> Coleen
>>>>>
>>>>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have a change out for review that fixes a huge pile of typos in the
>>>>>>> comments in the GC code. The RFR was sent to the GC list, but I want to give
>>>>>>> a heads up in case anyone else is changing GC code and want to avoid merge
>>>>>>> conflicts.
>>>>>>>
>>>>>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>>>>>
>>>>>>>
>>>>>>> There are also a few files where I happened to find a few typos "by
>>>>>>> accident"
>>>>>>> in code that is not strictly GC code. These are:
>>>>>>>
>>>>>>> src/share/vm/memory/heap.cpp
>>>>>>> src/share/vm/memory/heap.hpp
>>>>>>> src/share/vm/memory/allocation.hpp
>>>>>>> src/share/vm/memory/resourceArea.hpp
>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>
>>>>>>> There is a total of eight typos fixed in these files so I think the risk of
>>>>>>> merge conflicts here is minimal. Are there any objections to including these
>>>>>>> fixes in the change?
>>>>>>
>>>>>> Vote: go for it!
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> /Jesper
>>>>>>
>>>>>
>>>
>

From zhengyu.gu at oracle.com  Mon Jan 13 09:44:09 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 13 Jan 2014 12:44:09 -0500
Subject: RFR JDK-8031530: [TESTBUG] Enable test
	runtime/LoadClass/LoadClassNegative.java
In-Reply-To: <52D408D7.50504@oracle.com>
References: <52D041F9.5070904@oracle.com>	<268CA847-81C0-4E2F-8BAB-8FE1F17BEE4C@oracle.com>
	<F42008B6-63D1-48AC-96BD-9759AA6CBC49@oracle.com>
	<52D408D7.50504@oracle.com>
Message-ID: <D3A08544-843C-4ABE-9356-419271B91F6F@oracle.com>

Thanks for the review.

-Zhengyu

On Jan 13, 2014, at 10:40 AM, Coleen Phillmore wrote:

> 
> Looks good.
> Coleen
> 
> On 1/13/2014 8:40 AM, Zhengyu Gu wrote:
>> Thanks for the review.
>> 
>> -Zhengyu
>> 
>> On Jan 13, 2014, at 4:10 AM, Staffan Larsen wrote:
>> 
>>> Looks good!
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> On 10 jan 2014, at 19:54, Zhengyu Gu <zhengyu.gu at oracle.com> wrote:
>>> 
>>>> The test was disabled due to JDK-8028095,  which is a dup of JDK-8020675. The problem has been fixed, this test should be re-enabled.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031530
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8031530/webrev.00/ <http://cr.openjdk.java.net/%7Ezgu/8031530/webrev.00/>
>>>> 
>>>> Thanks,
>>>> 
>>>> -Zhengyu
> 


From mark.reinhold at oracle.com  Mon Jan 13 16:28:31 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 13 Jan 2014 16:28:31 -0800 (PST)
Subject: JEP 188: Java Memory Model Update
Message-ID: <20140114002831.9D3BAD7C5@eggemoggin.niobe.net>

Posted: http://openjdk.java.net/jeps/188

- Mark

From alejandro.murillo at oracle.com  Mon Jan 13 17:11:52 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Tue, 14 Jan 2014 01:11:52 +0000
Subject: hg: hsx/hsx25/hotspot: 6 new changesets
Message-ID: <20140114011207.366D2623D8@hg.openjdk.java.net>

Changeset: 591135a7d6f9
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/591135a7d6f9

Added tag jdk8-b122 for changeset d3521d8e562a

! .hgtags

Changeset: c89630a122b4
Author:    katleman
Date:      2014-01-10 08:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c89630a122b4

Added tag jdk8-b123 for changeset 591135a7d6f9

! .hgtags

Changeset: 9d39e8a8ff61
Author:    amurillo
Date:      2013-12-27 07:51 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9d39e8a8ff61

8031060: new hotspot build - hs25-b66
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: c3f3cfd39184
Author:    hseigel
Date:      2014-01-10 12:11 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c3f3cfd39184

8031059: invokestatic: ICCE trying to invoke static method when it clashes with an abstract method inherited from an interface
Summary: Do not create AME overpass if there is a matching static method
Reviewed-by: lfoltan, coleenp, kamg

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

Changeset: 9b9816164447
Author:    amurillo
Date:      2014-01-13 15:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9b9816164447

Merge


Changeset: ac902fca803b
Author:    amurillo
Date:      2014-01-13 15:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ac902fca803b

Added tag hs25-b66 for changeset 9b9816164447

! .hgtags


From alejandro.murillo at oracle.com  Mon Jan 13 18:14:45 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Tue, 14 Jan 2014 02:14:45 +0000
Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets
Message-ID: <20140114021456.EB4F7623DA@hg.openjdk.java.net>

Changeset: 591135a7d6f9
Author:    katleman
Date:      2014-01-03 11:54 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/591135a7d6f9

Added tag jdk8-b122 for changeset d3521d8e562a

! .hgtags

Changeset: c89630a122b4
Author:    katleman
Date:      2014-01-10 08:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c89630a122b4

Added tag jdk8-b123 for changeset 591135a7d6f9

! .hgtags

Changeset: 9b9816164447
Author:    amurillo
Date:      2014-01-13 15:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9b9816164447

Merge


Changeset: ac902fca803b
Author:    amurillo
Date:      2014-01-13 15:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ac902fca803b

Added tag hs25-b66 for changeset 9b9816164447

! .hgtags

Changeset: 16e0c6c84a91
Author:    amurillo
Date:      2014-01-13 16:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/16e0c6c84a91

8031553: new hotspot build - hs25-b67
Reviewed-by: jcoomes

! make/hotspot_version


From roland.westrelin at oracle.com  Tue Jan 14 02:11:06 2014
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Tue, 14 Jan 2014 10:11:06 +0000
Subject: hg: hsx/hotspot-main/hotspot: 8028764: dtrace/hotspot_jni/ALL/ALL001
	crashes the vm on Solaris-amd64,
	SIGSEGV in MarkSweep::follow_stack()+0x8a
Message-ID: <20140114101109.2F9E9623ED@hg.openjdk.java.net>

Changeset: 12ad8db39f76
Author:    roland
Date:      2014-01-14 09:44 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/12ad8db39f76

8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a
Summary: C1 generates code to encode compressed oop into tmp register before runtime call for patching where GC may happen
Reviewed-by: iveresov, twisti, kvn
Contributed-by: mgerdin <mikael.gerdin at oracle.com>

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp


From jesper.wilhelmsson at oracle.com  Tue Jan 14 05:38:07 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 14 Jan 2014 14:38:07 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>
References: <52CFEC4D.5000908@oracle.com>	<52D0141F.3070900@oracle.com>	<52D017CE.6090509@oracle.com>	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>	<52D3E50E.5040308@oracle.com>
	<CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>
Message-ID: <52D53DBF.9040500@oracle.com>

Sure, no problem. Webrev is updated, please verify.
I took the liberty of changing the layout of the comment in ciField.cpp. Since 
there was only one case left it didn't feel motivated to have a list of cases.
/Jesper

Krystal Mok skrev 13/1/14 7:36 PM:
> Hi Jesper,
>
> Thanks! I took a look and the change was fine.
>
> I do have a couple of other comment fixes that I'd like to hitchhike:
>
> 1. oops/method.hpp
>
> The comments say ConstMethod* and MethodData* are oops, which they aren't anymore.
> I'm not sure if the wording for "putting oops and method_size first for better
> gc cache locality" still matters. It probably doesn't matter anymore, since GC
> doesn't have to mark through these fields with the PermGen removal.
>
> 2. ci/ciField.hpp, ci/ciField.cpp
>
> The comments say in order to consider a field as a constant, it cannot hold an
> non-perm-space oop. I believe this limitation has been removed. Could someone
> from the compiler team verify if that's true?
>
> The diff is at the end of this mail.
>
> Thanks,
> Kris
>
> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
> --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800
> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800
> @@ -202,13 +202,9 @@
>       }
>       // This field just may be constant.  The only cases where it will
> -    // not be constant are:
> +    // not be constant is:
>       //
> -    // 1. The field holds a non-perm-space oop.  The field is, strictly
> -    //    speaking, constant but we cannot embed non-perm-space oops into
> -    //    generated code.  For the time being we need to consider the
> -    //    field to be not constant.
> -    // 2. The field is a *special* static&final field whose value
> +    // 1. The field is a *special* static&final field whose value
>       //    may change.  The three examples are java.lang.System.in
> <http://java.lang.System.in>,
>       //    java.lang.System.out, and java.lang.System.err.
> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
> --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800
> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800
> @@ -130,9 +130,7 @@
>     //   1. The field is both static and final
>     //   2. The canonical holder of the field has undergone
>     //      static initialization.
> -  //   3. If the field is an object or array, then the oop
> -  //      in question is allocated in perm space.
> -  //   4. The field is not one of the special static/final
> +  //   3. The field is not one of the special static/final
>     //      non-constant fields.  These are java.lang.System.in
> <http://java.lang.System.in>
>     //      and java.lang.System.out.  Abomination.
>     //
> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
> --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800
> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800
> @@ -38,13 +38,11 @@
>   #include "utilities/accessFlags.hpp"
>   #include "utilities/growableArray.hpp"
> -// A Method* represents a Java method.
> +// A Method represents a Java method.
>   //
>   // Memory layout (each line represents a word). Note that most applications
> load thousands of methods,
>   // so keeping the size of this structure small has a big impact on footprint.
>   //
> -// We put all oops and method_size first for better gc cache locality.
> -//
>   // The actual bytecodes are inlined after the end of the Method struct.
>   //
>   // There are bits in the access_flags telling whether inlined tables are present.
> @@ -64,17 +62,17 @@
>   // | header                                               |
>   // | klass                                                |
>   // |------------------------------------------------------|
> -// | ConstMethod*                   (oop)                 |
> +// | ConstMethod*                   (metadata)            |
>   // |------------------------------------------------------|
> -// | methodData                     (oop)                 |
> -// | methodCounters                                       |
> +// | MethodData*                    (metadata)            |
> +// | MethodCounters                                       |
>   // |------------------------------------------------------|
>   // | access_flags                                         |
>   // | vtable_index                                         |
>   // |------------------------------------------------------|
>   // | result_index (C++ interpreter only)                  |
>   // |------------------------------------------------------|
> -// | method_size             |   intrinsic_id|   flags    |
> +// | method_size             | intrinsic_id  |   flags    |
>   // |------------------------------------------------------|
>   // | code                           (pointer)             |
>   // | i2i                            (pointer)             |
>
>
>
>
> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson
> <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com>> wrote:
>
>     Hi Kris!
>
>     No problem, I'll add it to the change. Please verify that it looks OK in the
>     updated webrev (same link as before).
>
>     http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>     <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>
>
>     /Jesper
>
>
>     Krystal Mok skrev 10/1/14 7:17 PM:
>
>         Hi Jesper,
>
>         Nice to see cleaner code!
>
>         Hitchhike: It'd be nice if you could include this typo in:
>         http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html
>         <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html>
>         I didn't really like sending one-liner comment typo fix anyway...with a
>         lot of
>         other typos, the story is different ;-)
>
>         Thanks,
>         Kris
>
>
>
>         On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore
>         <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>
>         <mailto:coleen.phillimore at __oracle.com
>         <mailto:coleen.phillimore at oracle.com>>> wrote:
>
>              Seems fine with me also.  Could you find typos in the comments in the
>              runtime code "by accident" too? :)
>              thanks,
>              Coleen
>
>
>              On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>
>                  On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>
>                      Hi,
>
>                      I have a change out for review that fixes a huge pile of
>         typos in
>                      the comments in the GC code. The RFR was sent to the GC
>         list, but I
>                      want to give a heads up in case anyone else is changing GC
>         code and
>                      want to avoid merge conflicts.
>
>                      The patch:
>         http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/>
>
>                      <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>>
>
>
>                      There are also a few files where I happened to find a few
>         typos "by
>                      accident" in code that is not strictly GC code. These are:
>
>                      src/share/vm/memory/heap.cpp
>                      src/share/vm/memory/heap.hpp
>                      src/share/vm/memory/____allocation.hpp
>                      src/share/vm/memory/____resourceArea.hpp
>                      src/share/vm/runtime/thread.____cpp
>
>
>                      There is a total of eight typos fixed in these files so I
>         think the
>                      risk of merge conflicts here is minimal. Are there any
>         objections to
>                      including these fixes in the change?
>
>
>                  Vote: go for it!
>
>                  Dan
>
>
>                      Thanks,
>                      /Jesper
>
>
>
>
>

From goetz.lindenmaier at sap.com  Tue Jan 14 05:52:04 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 14 Jan 2014 13:52:04 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>

Hi,

I updated this webrev.  I detected a small flaw I made when editing this version.
The #endif in line 322, parse3.cpp was in the wrong line.
I also based the webrev on the latest version of the stage repo.
http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/

Best regards,
  Goetz.

-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Freitag, 20. Dezember 2013 13:47
To: David Holmes
Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Hi David,

> So we can at least undo #4 now we have established those tests were not 
> required to pass.
We would prefer if we could keep this in.  We want to avoid that it's
blamed on the VM if java programs are failing on PPC after they worked
on x86.  To clearly mark it as overfulfilling the spec I would guard it by 
a flag as proposed.  But if you insist I will remove it.  Also, this part is 
not that performance relevant.

> A compile-time guard (ifdef) would be better than a runtime one I think
I added a compile-time guard in this new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces 
several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC) 
but this way I only have to change the ppc platform.

Best regards,
  Goetz

P.S.:  I will also be available over the Christmas period.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Freitag, 20. Dezember 2013 05:58
To: Lindenmaier, Goetz
Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Sorry for the delay, it takes a while to catch up after two weeks 
vacation :) Next vacation (ie next two weeks) I'll continue to check emails.

On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> ok, I understand the tests are wrong.  It's good this issue is settled.
> Thanks Aleksey and Andreas for going into the details of the proof!
>
> About our change:  David, the causality is the other way round.
> The change is about IRIW.
> 1. To pass IRIW, we must use sync instructions before loads.

This is the part I still have some question marks over as the 
implications are not nice for performance on non-TSO platforms. But I'm 
no further along in processing that paper I'm afraid.

> 2. If we do syncs before loads, we don't need to do them after stores.
> 3. If we don't do them after stores, we fail the volatile constructor tests.
> 4. So finally we added them again at the end of the constructor after stores
>       to pass the volatile constructor tests.

So we can at least undo #4 now we have established those tests were not 
required to pass.

> We originally passed the constructor tests because the ppc memory order
> instructions are not as find-granular as the
> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
> MemBarVolatile after the store fixes the constructor tests.  The proper representation
> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
> anyways.
>
>> I'm not happy with the ifdef approach but I won't block it.
> I'd be happy to add a property
>    OrderAccess::cpu_is_multiple_copy_atomic()

A compile-time guard (ifdef) would be better than a runtime one I think 
- similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic 
based not architecture based) as that will allows for turning this 
on/off for any architecture for testing purposes.

Thanks,
David

> or the like to guard the customization.  I'd like that much better. Or also
>     OrderAccess::needs_support_iriw_ordering()
>     VM_Version::needs_support_iriw_ordering()
>
>
> Best regards,
>    Goetz.
>
>
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 28. November 2013 00:34
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> TL;DR version:
>
> Discussion on the c-i list has now confirmed that a constructor-barrier
> for volatiles is not required as part of the JMM specification. It *may*
> be required in an implementation that doesn't pre-zero memory to ensure
> you can't see uninitialized fields. So the tests for this are invalid
> and this part of the patch is not needed in general (ppc64 may need it
> due to other factors).
>
> Re: "multiple copy atomicity" - first thanks for correcting the term :)
> Second thanks for the reference to that paper! For reference:
>
> "The memory system (perhaps involving a hierarchy of buffers and a
> complex interconnect) does not guarantee that a write becomes visible to
> all other hardware threads at the same time point; these architectures
> are not multiple-copy atomic."
>
> This is the visibility issue that I referred to and affects both ARM and
> PPC. But of course it is normally handled by using suitable barriers
> after the stores that need to be visible. I think the crux of the
> current issue is what you wrote below:
>
>   > The fixes for the constructor issue are only needed because we
>   > remove the sync instruction from behind stores (parse3.cpp:320)
>   > and place it before loads.
>
> I hadn't grasped this part. Obviously if you fail to do the sync after
> the store then you have to do something around the loads to get the same
> results! I still don't know what lead you to the conclusion that the
> only way to fix the IRIW issue was to put the fence before the load -
> maybe when I get the chance to read that paper in full it will be clearer.
>
> So ... the basic problem is that the current structure in the VM has
> hard-wired one choice of how to get the right semantics for volatile
> variables. You now want to customize that but not all the requisite
> hooks are present. It would be better if volatile_load and
> volatile_store were factored out so that they could be implemented as
> desired per-platform. Alternatively there could be pre- and post- hooks
> that could then be customized per platform. Otherwise you need
> platform-specific ifdef's to handle it as per your patch.
>
> I'm not happy with the ifdef approach but I won't block it. I think this
> is an area where a lot of clean up is needed in the VM. The barrier
> abstractions are a confused mess in my opinion.
>
> Thanks,
> David
> -----
>
> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I updated the webrev to fix the issues mentioned by Vladimir:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>
>> I did not yet add the
>>      OrderAccess::needs_support_iriw_ordering()
>>      VM_Version::needs_support_iriw_ordering()
>> or
>>     OrderAccess::cpu_is_multiple_copy_atomic()
>> to reduce #defined, as I got no further comment on that.
>>
>>
>> WRT to the validity of the tests and the interpretation of the JMM
>> I feel not in the position to contribute substantially.
>>
>> But we would like to pass the torture test suite as we consider
>> this a substantial task in implementing a PPC port.  Also we think
>> both tests show behavior a programmer would expect.  It's bad if
>> Java code runs fine on the more common x86 platform, and then
>> fails on ppc.  This will always first be blamed on the VM.
>>
>> The fixes for the constructor issue are only needed because we
>> remove the sync instruction from behind stores (parse3.cpp:320)
>> and place it before loads.  Then there is no sync between volatile store
>> and publishing the object.  So we add it again in this one case
>> (volatile store in constructor).
>>
>>
>> @David
>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>> and that's being discussed now for almost a year.
>>> It may have started a year ago but work on it has hardly been continuous.
>> That's not true, we did a lot of investigation and testing on this issue.
>> And we came up with a solution we consider the best possible. If you
>> have objections, you should at least give the draft of a better solution,
>> we would volunteer to implement and test it.
>> Similarly, we invested time in fixing the concurrency torture issues.
>>
>> @David
>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>> can't find any reference to it.
>> We learned about this reading "A Tutorial Introduction to the ARM and
>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>
>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>
>> Best regards and thanks for all your involvements,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Mittwoch, 27. November 2013 12:53
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz,
>>
>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> -- Volatile in constuctor
>>>> AFAIK we have not seen those tests fail due to a
>>>> missing constructor barrier.
>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>
>> And see follow ups - the tests are invalid.
>>
>>> -- IRIW issue
>>>> I can not possibly answer to the necessary level of detail with a few
>>>> moments thought.
>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>> and that's being discussed now for almost a year.
>>
>> It may have started a year ago but work on it has hardly been continuous.
>>
>>>> You are implying there is a problem here that will
>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>> (I don't really know about ARM, though).
>>> So if I can write down a nicer solution testing for methods that are evaluated
>>> by the C-compiler I'm happy.
>>>
>>> The problem is not that IRIW is not handled by the JMM, the problem
>>> is that
>>>      store
>>>      sync
>>> does not assure multiple-read-atomicity,
>>> only
>>>      sync
>>>      load
>>> does so on PPC.  And you require multiple-read-atomicity to
>>> pass that test.
>>
>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>> can't find any reference to it.
>>
>> Thanks,
>> David
>>
>>      The JMM is fine. And
>>>      store
>>>      MemBarVolatile
>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>> do what is required.
>>>
>>> So if you are off soon, please let's come to a solution that
>>> might be improvable in the way it's implemented, but that
>>> allows us to implement a correct PPC64 port.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>> To: Lindenmaier, Goetz
>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>> Hi everybody,
>>>>
>>>> thanks a lot for the detailed reviews!
>>>> I'll try to answer to all in one mail.
>>>>
>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>> We don't think it's correct if we omit the barrier after initializing
>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>> and Doug Lea, and they agreed.
>>>> Also, concurrency torture tests
>>>>        LongVolatileTest
>>>>        AtomicIntegerInitialValueTest
>>>> will fail.
>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>
>>> The affects of unsafe publication are always surprising - volatiles do
>>> not add anything special here. AFAIK there is nothing in the JMM that
>>> requires the constructor barrier - discussions with Doug and Aleksey
>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>> missing constructor barrier.
>>>
>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>> see a way to implement this cheaper.
>>>>
>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>> Basically, I agree on this.  But you also have to take into account
>>>> that due to the different memory ordering instructions on different platforms
>>>> just implementing something empty is not sufficient.
>>>> An example:
>>>>       MemBarRelease    // means LoadStore, StoreStore barrier
>>>>       MemBarVolatile    // means  StoreLoad barrier
>>>> If these are consecutively in the code, sparc code looks like this:
>>>>       MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>       MemBarVolatile --> membar(Assembler::StoreLoad)
>>>> Just doing what is required.
>>>> On Power, we get suboptimal code, as there are no comparable,
>>>> fine grained operations:
>>>>        MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>       MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>> MemBarRelease empty, as it is also used independently.
>>>>
>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>
>>>> I would propose to guard the code by
>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>> Else, David, how would you propose to implement this platform independent?
>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>
>>> I can not possibly answer to the necessary level of detail with a few
>>> moments thought. You are implying there is a problem here that will
>>> impact numerous platforms (unless you can tell me why ppc is so
>>> different?) and I can not take that on face value at the moment. The
>>> only reason I can see IRIW not being handled by the JMM requirements for
>>> volatile accesses is if there are global visibility issues that are not
>>> addressed - but even then I would expect heavy barriers at the store
>>> would deal with that, not at the load. (This situation reminds me of the
>>> need for read-barriers on Alpha architecture due to the use of software
>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>> that on ppc!)
>>>
>>> Sorry - There is no quick resolution here and in a couple of days I will
>>> be heading out on vacation for two weeks.
>>>
>>> David
>>> -----
>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>> -- Other ports:
>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>
>>>> -- MemBarStoreStore after initialization
>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>> prepare an extra webrev for hotspot-comp.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>> To: Vladimir Kozlov
>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>
>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>> I have to ask David to do correctness evaluation.
>>>>
>>>>      From what I understand what we see here is an attempt to fix an
>>>> existing issue with the implementation of volatiles so that the IRIW
>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>> load.
>>>>
>>>> Now if this was purely handled in ppc64 source code then I would be
>>>> happy to let them do whatever they like (surely this kills performance
>>>> though!). But I do not agree with the changes to the shared code that
>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>> polluting the shared code. My concern is similar to what I said with the
>>>> taskQueue changes - these algorithms should be expressed using the
>>>> correct OrderAccess operations to guarantee the desired properties
>>>> independent of architecture. If such a "barrier" is not needed on a
>>>> given architecture then the implementation in OrderAccess should reduce
>>>> to a no-op.
>>>>
>>>> And as Vitaly points out the constructor barriers are not needed under
>>>> the JMM.
>>>>
>>>>> I am fine with suggested changes because you did not change our current
>>>>> code for our platforms (please, do not change do_exits() now).
>>>>> But may be it should be done using more general query which is set
>>>>> depending on platform:
>>>>>
>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>
>>>>> or similar to what we use now:
>>>>>
>>>>> VM_Version::needs_support_iriw_ordering()
>>>>
>>>> Every platform has to support IRIW this is simply part of the Java
>>>> Memory Model, there should not be any need to call this out explicitly
>>>> like this.
>>>>
>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>      From what I understand our ppc port is also affected. David?
>>>>
>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>
>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>
>>>>> In do_put_xxx() can you combine your changes:
>>>>>
>>>>>         if (is_vol) {
>>>>>           // See comment in do_get_xxx().
>>>>> #ifndef PPC64
>>>>>           insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>> #else
>>>>>           if (is_field) {
>>>>>             // Add MemBarRelease for constructors which write volatile field
>>>>> (PPC64).
>>>>>             set_wrote_volatile(true);
>>>>>           }
>>>>> #endif
>>>>>         }
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>> the torture test suite:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>
>>>>>> Example:
>>>>>> volatile x=0, y=0
>>>>>>        __________    __________    __________    __________
>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>
>>>>>>         write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>                       read(y)                     read(x)
>>>>>>
>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>
>>>>>>
>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>
>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>
>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>> written in constructors are visible before the reference gets
>>>>>> published.
>>>>>>
>>>>>>
>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>> strong.
>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>> What do you think?
>>>>>>
>>>>>> Please review and test this change.
>>>>>>
>>>>>> Best regards,
>>>>>>        Goetz.
>>>>>>

From rednaxelafx at gmail.com  Tue Jan 14 09:53:34 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Wed, 15 Jan 2014 01:53:34 +0800
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D53DBF.9040500@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com>
	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>
	<52D3E50E.5040308@oracle.com>
	<CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>
	<52D53DBF.9040500@oracle.com>
Message-ID: <CA+cQ+tS+hytNx55hazNTPDHQ1qrnx=-QYGp_hCM=f84bCaZ2EQ@mail.gmail.com>

Hi Jesper,

That looks fine to me. Thank you!
It's still better if someone from the runtime team could verify the change
in oops/method.hpp, and someone from the compiler team could verify the
change in ci/ciField.hpp|cpp

Thanks,
Kris


On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson <
jesper.wilhelmsson at oracle.com> wrote:

> Sure, no problem. Webrev is updated, please verify.
> I took the liberty of changing the layout of the comment in ciField.cpp.
> Since there was only one case left it didn't feel motivated to have a list
> of cases.
> /Jesper
>
> Krystal Mok skrev 13/1/14 7:36 PM:
>
>> Hi Jesper,
>>
>> Thanks! I took a look and the change was fine.
>>
>> I do have a couple of other comment fixes that I'd like to hitchhike:
>>
>> 1. oops/method.hpp
>>
>> The comments say ConstMethod* and MethodData* are oops, which they aren't
>> anymore.
>> I'm not sure if the wording for "putting oops and method_size first for
>> better
>> gc cache locality" still matters. It probably doesn't matter anymore,
>> since GC
>> doesn't have to mark through these fields with the PermGen removal.
>>
>> 2. ci/ciField.hpp, ci/ciField.cpp
>>
>> The comments say in order to consider a field as a constant, it cannot
>> hold an
>> non-perm-space oop. I believe this limitation has been removed. Could
>> someone
>> from the compiler team verify if that's true?
>>
>> The diff is at the end of this mail.
>>
>> Thanks,
>> Kris
>>
>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
>> --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800
>> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800
>>
>> @@ -202,13 +202,9 @@
>>       }
>>       // This field just may be constant.  The only cases where it will
>> -    // not be constant are:
>> +    // not be constant is:
>>       //
>> -    // 1. The field holds a non-perm-space oop.  The field is, strictly
>> -    //    speaking, constant but we cannot embed non-perm-space oops into
>> -    //    generated code.  For the time being we need to consider the
>> -    //    field to be not constant.
>> -    // 2. The field is a *special* static&final field whose value
>> +    // 1. The field is a *special* static&final field whose value
>>       //    may change.  The three examples are java.lang.System.in
>> <http://java.lang.System.in>,
>>
>>       //    java.lang.System.out, and java.lang.System.err.
>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
>> --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800
>> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800
>>
>> @@ -130,9 +130,7 @@
>>     //   1. The field is both static and final
>>     //   2. The canonical holder of the field has undergone
>>     //      static initialization.
>> -  //   3. If the field is an object or array, then the oop
>> -  //      in question is allocated in perm space.
>> -  //   4. The field is not one of the special static/final
>> +  //   3. The field is not one of the special static/final
>>     //      non-constant fields.  These are java.lang.System.in
>> <http://java.lang.System.in>
>>
>>     //      and java.lang.System.out.  Abomination.
>>     //
>> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
>> --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800
>> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800
>>
>> @@ -38,13 +38,11 @@
>>   #include "utilities/accessFlags.hpp"
>>   #include "utilities/growableArray.hpp"
>> -// A Method* represents a Java method.
>> +// A Method represents a Java method.
>>   //
>>   // Memory layout (each line represents a word). Note that most
>> applications
>> load thousands of methods,
>>   // so keeping the size of this structure small has a big impact on
>> footprint.
>>   //
>> -// We put all oops and method_size first for better gc cache locality.
>> -//
>>   // The actual bytecodes are inlined after the end of the Method struct.
>>   //
>>   // There are bits in the access_flags telling whether inlined tables
>> are present.
>> @@ -64,17 +62,17 @@
>>   // | header                                               |
>>   // | klass                                                |
>>   // |------------------------------------------------------|
>> -// | ConstMethod*                   (oop)                 |
>> +// | ConstMethod*                   (metadata)            |
>>   // |------------------------------------------------------|
>> -// | methodData                     (oop)                 |
>> -// | methodCounters                                       |
>> +// | MethodData*                    (metadata)            |
>> +// | MethodCounters                                       |
>>   // |------------------------------------------------------|
>>   // | access_flags                                         |
>>   // | vtable_index                                         |
>>   // |------------------------------------------------------|
>>   // | result_index (C++ interpreter only)                  |
>>   // |------------------------------------------------------|
>> -// | method_size             |   intrinsic_id|   flags    |
>> +// | method_size             | intrinsic_id  |   flags    |
>>   // |------------------------------------------------------|
>>   // | code                           (pointer)             |
>>   // | i2i                            (pointer)             |
>>
>>
>>
>>
>> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson
>> <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com>>
>> wrote:
>>
>>     Hi Kris!
>>
>>     No problem, I'll add it to the change. Please verify that it looks OK
>> in the
>>     updated webrev (same link as before).
>>
>>     http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>
>>     <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>
>>
>>     /Jesper
>>
>>
>>     Krystal Mok skrev 10/1/14 7:17 PM:
>>
>>         Hi Jesper,
>>
>>         Nice to see cleaner code!
>>
>>         Hitchhike: It'd be nice if you could include this typo in:
>>         http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__
>> dev/2014-January/012944.html
>>
>>         <http://mail.openjdk.java.net/pipermail/hotspot-compiler-
>> dev/2014-January/012944.html>
>>         I didn't really like sending one-liner comment typo fix
>> anyway...with a
>>         lot of
>>         other typos, the story is different ;-)
>>
>>         Thanks,
>>         Kris
>>
>>
>>
>>         On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore
>>         <coleen.phillimore at oracle.com <mailto:coleen.phillimore@
>> oracle.com>
>>         <mailto:coleen.phillimore at __oracle.com
>>
>>         <mailto:coleen.phillimore at oracle.com>>> wrote:
>>
>>              Seems fine with me also.  Could you find typos in the
>> comments in the
>>              runtime code "by accident" too? :)
>>              thanks,
>>              Coleen
>>
>>
>>              On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>
>>                  On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>
>>                      Hi,
>>
>>                      I have a change out for review that fixes a huge
>> pile of
>>         typos in
>>                      the comments in the GC code. The RFR was sent to the
>> GC
>>         list, but I
>>                      want to give a heads up in case anyone else is
>> changing GC
>>         code and
>>                      want to avoid merge conflicts.
>>
>>                      The patch:
>>         http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/
>>         <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/>
>>
>>
>>                      <http://cr.openjdk.java.net/~_
>> _jwilhelm/8025856/webrev.1/
>>         <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>>
>>
>>
>>                      There are also a few files where I happened to find
>> a few
>>         typos "by
>>                      accident" in code that is not strictly GC code.
>> These are:
>>
>>                      src/share/vm/memory/heap.cpp
>>                      src/share/vm/memory/heap.hpp
>>                      src/share/vm/memory/____allocation.hpp
>>                      src/share/vm/memory/____resourceArea.hpp
>>                      src/share/vm/runtime/thread.____cpp
>>
>>
>>
>>                      There is a total of eight typos fixed in these files
>> so I
>>         think the
>>                      risk of merge conflicts here is minimal. Are there
>> any
>>         objections to
>>                      including these fixes in the change?
>>
>>
>>                  Vote: go for it!
>>
>>                  Dan
>>
>>
>>                      Thanks,
>>                      /Jesper
>>
>>
>>
>>
>>
>>

From coleen.phillimore at oracle.com  Tue Jan 14 10:46:36 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 14 Jan 2014 13:46:36 -0500
Subject: Changing lots of files - mainly GC code
In-Reply-To: <CA+cQ+tS+hytNx55hazNTPDHQ1qrnx=-QYGp_hCM=f84bCaZ2EQ@mail.gmail.com>
References: <52CFEC4D.5000908@oracle.com>	<52D0141F.3070900@oracle.com>	<52D017CE.6090509@oracle.com>	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>	<52D3E50E.5040308@oracle.com>	<CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>	<52D53DBF.9040500@oracle.com>
	<CA+cQ+tS+hytNx55hazNTPDHQ1qrnx=-QYGp_hCM=f84bCaZ2EQ@mail.gmail.com>
Message-ID: <52D5860C.4010107@oracle.com>


These changes you have look good for Method except a lot of the comment 
is out of date.  The block comment about the layout of fields in Method 
is redundant with the actual declaration and wrong.  It's a nice visual 
but I don't see the point of keeping redundant information like that.  
Also, it the comment describes some of the fields that were moved to 
ConstMethod years ago.   I don't think you want to try to correct these 
things with this typo change, but we should (I could) file an RFE to 
correct them later.

thanks,
Coleen

On 01/14/2014 12:53 PM, Krystal Mok wrote:
> Hi Jesper,
>
> That looks fine to me. Thank you!
> It's still better if someone from the runtime team could verify the 
> change in oops/method.hpp, and someone from the compiler team could 
> verify the change in ci/ciField.hpp|cpp
>
> Thanks,
> Kris
>
>
> On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson 
> <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com>> 
> wrote:
>
>     Sure, no problem. Webrev is updated, please verify.
>     I took the liberty of changing the layout of the comment in
>     ciField.cpp. Since there was only one case left it didn't feel
>     motivated to have a list of cases.
>     /Jesper
>
>     Krystal Mok skrev 13/1/14 7:36 PM:
>
>         Hi Jesper,
>
>         Thanks! I took a look and the change was fine.
>
>         I do have a couple of other comment fixes that I'd like to
>         hitchhike:
>
>         1. oops/method.hpp
>
>         The comments say ConstMethod* and MethodData* are oops, which
>         they aren't anymore.
>         I'm not sure if the wording for "putting oops and method_size
>         first for better
>         gc cache locality" still matters. It probably doesn't matter
>         anymore, since GC
>         doesn't have to mark through these fields with the PermGen
>         removal.
>
>         2. ci/ciField.hpp, ci/ciField.cpp
>
>         The comments say in order to consider a field as a constant,
>         it cannot hold an
>         non-perm-space oop. I believe this limitation has been
>         removed. Could someone
>         from the compiler team verify if that's true?
>
>         The diff is at the end of this mail.
>
>         Thanks,
>         Kris
>
>         diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
>         --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800
>         +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800
>
>         @@ -202,13 +202,9 @@
>               }
>               // This field just may be constant.  The only cases
>         where it will
>         -    // not be constant are:
>         +    // not be constant is:
>               //
>         -    // 1. The field holds a non-perm-space oop.  The field
>         is, strictly
>         -    //    speaking, constant but we cannot embed
>         non-perm-space oops into
>         -    //    generated code.  For the time being we need to
>         consider the
>         -    //    field to be not constant.
>         -    // 2. The field is a *special* static&final field whose value
>         +    // 1. The field is a *special* static&final field whose value
>               //    may change.  The three examples are
>         java.lang.System.in <http://java.lang.System.in>
>         <http://java.lang.System.in>,
>
>               //    java.lang.System.out, and java.lang.System.err.
>         diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
>         --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800
>         +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800
>
>         @@ -130,9 +130,7 @@
>             //   1. The field is both static and final
>             //   2. The canonical holder of the field has undergone
>             //      static initialization.
>         -  //   3. If the field is an object or array, then the oop
>         -  //      in question is allocated in perm space.
>         -  //   4. The field is not one of the special static/final
>         +  //   3. The field is not one of the special static/final
>             //      non-constant fields.  These are
>         java.lang.System.in <http://java.lang.System.in>
>         <http://java.lang.System.in>
>
>             //      and java.lang.System.out.  Abomination.
>             //
>         diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
>         --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800
>         +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800
>
>         @@ -38,13 +38,11 @@
>           #include "utilities/accessFlags.hpp"
>           #include "utilities/growableArray.hpp"
>         -// A Method* represents a Java method.
>         +// A Method represents a Java method.
>           //
>           // Memory layout (each line represents a word). Note that
>         most applications
>         load thousands of methods,
>           // so keeping the size of this structure small has a big
>         impact on footprint.
>           //
>         -// We put all oops and method_size first for better gc cache
>         locality.
>         -//
>           // The actual bytecodes are inlined after the end of the
>         Method struct.
>           //
>           // There are bits in the access_flags telling whether
>         inlined tables are present.
>         @@ -64,17 +62,17 @@
>           // | header       |
>           // | klass      |
>           // |------------------------------------------------------|
>         -// | ConstMethod*                   (oop)     |
>         +// | ConstMethod*                   (metadata)      |
>           // |------------------------------------------------------|
>         -// | methodData                     (oop)     |
>         -// | methodCounters     |
>         +// | MethodData*                    (metadata)      |
>         +// | MethodCounters     |
>           // |------------------------------------------------------|
>           // | access_flags       |
>           // | vtable_index       |
>           // |------------------------------------------------------|
>           // | result_index (C++ interpreter only)      |
>           // |------------------------------------------------------|
>         -// | method_size             |   intrinsic_id| flags    |
>         +// | method_size             | intrinsic_id  | flags    |
>           // |------------------------------------------------------|
>           // | code                           (pointer)       |
>           // | i2i                            (pointer)       |
>
>
>
>
>         On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson
>         <jesper.wilhelmsson at oracle.com
>         <mailto:jesper.wilhelmsson at oracle.com>
>         <mailto:jesper.wilhelmsson at oracle.com
>         <mailto:jesper.wilhelmsson at oracle.com>>> wrote:
>
>             Hi Kris!
>
>             No problem, I'll add it to the change. Please verify that
>         it looks OK in the
>             updated webrev (same link as before).
>
>         http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/%7E__jwilhelm/8025856/webrev.1/>
>
>             <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/%7Ejwilhelm/8025856/webrev.1/>>
>
>             /Jesper
>
>
>             Krystal Mok skrev 10/1/14 7:17 PM:
>
>                 Hi Jesper,
>
>                 Nice to see cleaner code!
>
>                 Hitchhike: It'd be nice if you could include this typo in:
>         http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html
>
>
>                
>         <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html>
>                 I didn't really like sending one-liner comment typo
>         fix anyway...with a
>                 lot of
>                 other typos, the story is different ;-)
>
>                 Thanks,
>                 Kris
>
>
>
>                 On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore
>                 <coleen.phillimore at oracle.com
>         <mailto:coleen.phillimore at oracle.com>
>         <mailto:coleen.phillimore at oracle.com
>         <mailto:coleen.phillimore at oracle.com>>
>                 <mailto:coleen.phillimore@
>         <mailto:coleen.phillimore@>__oracle.com <http://oracle.com>
>
>                 <mailto:coleen.phillimore at oracle.com
>         <mailto:coleen.phillimore at oracle.com>>>> wrote:
>
>                      Seems fine with me also.  Could you find typos in
>         the comments in the
>                      runtime code "by accident" too? :)
>                      thanks,
>                      Coleen
>
>
>                      On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>
>                          On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>
>                              Hi,
>
>                              I have a change out for review that fixes
>         a huge pile of
>                 typos in
>                              the comments in the GC code. The RFR was
>         sent to the GC
>                 list, but I
>                              want to give a heads up in case anyone
>         else is changing GC
>                 code and
>                              want to avoid merge conflicts.
>
>                              The patch:
>         http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/%7E____jwilhelm/8025856/webrev.1/>
>                
>         <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/%7E__jwilhelm/8025856/webrev.1/>>
>
>
>                            
>          <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/%7E__jwilhelm/8025856/webrev.1/>
>                
>         <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>         <http://cr.openjdk.java.net/%7Ejwilhelm/8025856/webrev.1/>>>
>
>
>                              There are also a few files where I
>         happened to find a few
>                 typos "by
>                              accident" in code that is not strictly GC
>         code. These are:
>
>                              src/share/vm/memory/heap.cpp
>                              src/share/vm/memory/heap.hpp
>                              src/share/vm/memory/____allocation.hpp
>                              src/share/vm/memory/____resourceArea.hpp
>                              src/share/vm/runtime/thread.____cpp
>
>
>
>                              There is a total of eight typos fixed in
>         these files so I
>                 think the
>                              risk of merge conflicts here is minimal.
>         Are there any
>                 objections to
>                              including these fixes in the change?
>
>
>                          Vote: go for it!
>
>                          Dan
>
>
>                              Thanks,
>                              /Jesper
>
>
>
>
>
>


From rednaxelafx at gmail.com  Tue Jan 14 11:29:21 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Wed, 15 Jan 2014 03:29:21 +0800
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D5860C.4010107@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com>
	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>
	<52D3E50E.5040308@oracle.com>
	<CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>
	<52D53DBF.9040500@oracle.com>
	<CA+cQ+tS+hytNx55hazNTPDHQ1qrnx=-QYGp_hCM=f84bCaZ2EQ@mail.gmail.com>
	<52D5860C.4010107@oracle.com>
Message-ID: <CA+cQ+tRPJs+YWhDh9Nf-7GvzVzgseVwLiYv4Z81=qiyBjfq88A@mail.gmail.com>

Hi Coleen,

Thanks for the review. I'm all for getting things right, and I agree
there's more comments that needs some love.
I'm okay with leaving the changes in method.hpp out for now, and correct
them later.

Thanks,
Kris


On Wed, Jan 15, 2014 at 2:46 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
> These changes you have look good for Method except a lot of the comment is
> out of date.  The block comment about the layout of fields in Method is
> redundant with the actual declaration and wrong.  It's a nice visual but I
> don't see the point of keeping redundant information like that.  Also, it
> the comment describes some of the fields that were moved to ConstMethod
> years ago.   I don't think you want to try to correct these things with
> this typo change, but we should (I could) file an RFE to correct them later.
>
> thanks,
> Coleen
>
>
> On 01/14/2014 12:53 PM, Krystal Mok wrote:
>
> Hi Jesper,
>
>  That looks fine to me. Thank you!
> It's still better if someone from the runtime team could verify the change
> in oops/method.hpp, and someone from the compiler team could verify the
> change in ci/ciField.hpp|cpp
>
>  Thanks,
> Kris
>
>
> On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson <
> jesper.wilhelmsson at oracle.com> wrote:
>
>> Sure, no problem. Webrev is updated, please verify.
>> I took the liberty of changing the layout of the comment in ciField.cpp.
>> Since there was only one case left it didn't feel motivated to have a list
>> of cases.
>> /Jesper
>>
>> Krystal Mok skrev 13/1/14 7:36 PM:
>>
>>>  Hi Jesper,
>>>
>>> Thanks! I took a look and the change was fine.
>>>
>>> I do have a couple of other comment fixes that I'd like to hitchhike:
>>>
>>> 1. oops/method.hpp
>>>
>>> The comments say ConstMethod* and MethodData* are oops, which they
>>> aren't anymore.
>>> I'm not sure if the wording for "putting oops and method_size first for
>>> better
>>> gc cache locality" still matters. It probably doesn't matter anymore,
>>> since GC
>>> doesn't have to mark through these fields with the PermGen removal.
>>>
>>> 2. ci/ciField.hpp, ci/ciField.cpp
>>>
>>> The comments say in order to consider a field as a constant, it cannot
>>> hold an
>>> non-perm-space oop. I believe this limitation has been removed. Could
>>> someone
>>> from the compiler team verify if that's true?
>>>
>>> The diff is at the end of this mail.
>>>
>>> Thanks,
>>> Kris
>>>
>>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
>>>  --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800
>>> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800
>>>
>>> @@ -202,13 +202,9 @@
>>>       }
>>>       // This field just may be constant.  The only cases where it will
>>> -    // not be constant are:
>>> +    // not be constant is:
>>>       //
>>> -    // 1. The field holds a non-perm-space oop.  The field is, strictly
>>> -    //    speaking, constant but we cannot embed non-perm-space oops
>>> into
>>> -    //    generated code.  For the time being we need to consider the
>>> -    //    field to be not constant.
>>> -    // 2. The field is a *special* static&final field whose value
>>> +    // 1. The field is a *special* static&final field whose value
>>>       //    may change.  The three examples are java.lang.System.in
>>>  <http://java.lang.System.in>,
>>>
>>>       //    java.lang.System.out, and java.lang.System.err.
>>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
>>>  --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800
>>> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800
>>>
>>> @@ -130,9 +130,7 @@
>>>     //   1. The field is both static and final
>>>     //   2. The canonical holder of the field has undergone
>>>     //      static initialization.
>>> -  //   3. If the field is an object or array, then the oop
>>> -  //      in question is allocated in perm space.
>>> -  //   4. The field is not one of the special static/final
>>> +  //   3. The field is not one of the special static/final
>>>     //      non-constant fields.  These are java.lang.System.in
>>>  <http://java.lang.System.in>
>>>
>>>     //      and java.lang.System.out.  Abomination.
>>>     //
>>> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
>>>  --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800
>>> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800
>>>
>>> @@ -38,13 +38,11 @@
>>>   #include "utilities/accessFlags.hpp"
>>>   #include "utilities/growableArray.hpp"
>>> -// A Method* represents a Java method.
>>> +// A Method represents a Java method.
>>>   //
>>>   // Memory layout (each line represents a word). Note that most
>>> applications
>>> load thousands of methods,
>>>   // so keeping the size of this structure small has a big impact on
>>> footprint.
>>>   //
>>> -// We put all oops and method_size first for better gc cache locality.
>>> -//
>>>   // The actual bytecodes are inlined after the end of the Method struct.
>>>   //
>>>   // There are bits in the access_flags telling whether inlined tables
>>> are present.
>>> @@ -64,17 +62,17 @@
>>>   // | header                                               |
>>>   // | klass                                                |
>>>   // |------------------------------------------------------|
>>> -// | ConstMethod*                   (oop)                 |
>>> +// | ConstMethod*                   (metadata)            |
>>>   // |------------------------------------------------------|
>>> -// | methodData                     (oop)                 |
>>> -// | methodCounters                                       |
>>> +// | MethodData*                    (metadata)            |
>>> +// | MethodCounters                                       |
>>>   // |------------------------------------------------------|
>>>   // | access_flags                                         |
>>>   // | vtable_index                                         |
>>>   // |------------------------------------------------------|
>>>   // | result_index (C++ interpreter only)                  |
>>>   // |------------------------------------------------------|
>>> -// | method_size             |   intrinsic_id|   flags    |
>>> +// | method_size             | intrinsic_id  |   flags    |
>>>   // |------------------------------------------------------|
>>>   // | code                           (pointer)             |
>>>   // | i2i                            (pointer)             |
>>>
>>>
>>>
>>>
>>> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson
>>>   <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com>>
>>> wrote:
>>>
>>>     Hi Kris!
>>>
>>>     No problem, I'll add it to the change. Please verify that it looks
>>> OK in the
>>>     updated webrev (same link as before).
>>>
>>>      http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>>
>>>     <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>
>>>
>>>     /Jesper
>>>
>>>
>>>     Krystal Mok skrev 10/1/14 7:17 PM:
>>>
>>>         Hi Jesper,
>>>
>>>         Nice to see cleaner code!
>>>
>>>         Hitchhike: It'd be nice if you could include this typo in:
>>>
>>> http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html
>>>
>>>         <
>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html
>>> >
>>>         I didn't really like sending one-liner comment typo fix
>>> anyway...with a
>>>         lot of
>>>         other typos, the story is different ;-)
>>>
>>>         Thanks,
>>>         Kris
>>>
>>>
>>>
>>>         On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore
>>>         <coleen.phillimore at oracle.com <mailto:
>>> coleen.phillimore at oracle.com>
>>>          <mailto:coleen.phillimore at __oracle.com
>>>
>>>         <mailto:coleen.phillimore at oracle.com>>> wrote:
>>>
>>>              Seems fine with me also.  Could you find typos in the
>>> comments in the
>>>              runtime code "by accident" too? :)
>>>              thanks,
>>>              Coleen
>>>
>>>
>>>              On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>
>>>                  On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>
>>>                      Hi,
>>>
>>>                      I have a change out for review that fixes a huge
>>> pile of
>>>         typos in
>>>                      the comments in the GC code. The RFR was sent to
>>> the GC
>>>         list, but I
>>>                      want to give a heads up in case anyone else is
>>> changing GC
>>>         code and
>>>                      want to avoid merge conflicts.
>>>
>>>                      The patch:
>>>          http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/
>>>         <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/>
>>>
>>>
>>>                      <
>>> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>>         <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>>
>>>
>>>
>>>                      There are also a few files where I happened to find
>>> a few
>>>         typos "by
>>>                      accident" in code that is not strictly GC code.
>>> These are:
>>>
>>>                      src/share/vm/memory/heap.cpp
>>>                      src/share/vm/memory/heap.hpp
>>>                       src/share/vm/memory/____allocation.hpp
>>>                      src/share/vm/memory/____resourceArea.hpp
>>>                      src/share/vm/runtime/thread.____cpp
>>>
>>>
>>>
>>>                      There is a total of eight typos fixed in these
>>> files so I
>>>         think the
>>>                      risk of merge conflicts here is minimal. Are there
>>> any
>>>         objections to
>>>                      including these fixes in the change?
>>>
>>>
>>>                  Vote: go for it!
>>>
>>>                  Dan
>>>
>>>
>>>                      Thanks,
>>>                      /Jesper
>>>
>>>
>>>
>>>
>>>
>>>
>
>

From coleen.phillimore at oracle.com  Tue Jan 14 12:40:54 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 14 Jan 2014 15:40:54 -0500
Subject: Changing lots of files - mainly GC code
In-Reply-To: <CA+cQ+tRPJs+YWhDh9Nf-7GvzVzgseVwLiYv4Z81=qiyBjfq88A@mail.gmail.com>
References: <52CFEC4D.5000908@oracle.com>	<52D0141F.3070900@oracle.com>	<52D017CE.6090509@oracle.com>	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>	<52D3E50E.5040308@oracle.com>	<CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>	<52D53DBF.9040500@oracle.com>	<CA+cQ+tS+hytNx55hazNTPDHQ1qrnx=-QYGp_hCM=f84bCaZ2EQ@mail.gmail.com>	<52D5860C.4010107@oracle.com>
	<CA+cQ+tRPJs+YWhDh9Nf-7GvzVzgseVwLiYv4Z81=qiyBjfq88A@mail.gmail.com>
Message-ID: <52D5A0D6.3090602@oracle.com>


On 01/14/2014 02:29 PM, Krystal Mok wrote:
> Hi Coleen,
>
> Thanks for the review. I'm all for getting things right, and I agree 
> there's more comments that needs some love.
> I'm okay with leaving the changes in method.hpp out for now, and 
> correct them later.

The ones you and Jesper have so far are fine.  You can leave them in.   
I would like you to leave them in.   I was only pointing out that there 
are more changes needed that could be done by themselves later.

Coleen

>
> Thanks,
> Kris
>
>
> On Wed, Jan 15, 2014 at 2:46 AM, Coleen Phillimore 
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> 
> wrote:
>
>
>     These changes you have look good for Method except a lot of the
>     comment is out of date.  The block comment about the layout of
>     fields in Method is redundant with the actual declaration and
>     wrong.  It's a nice visual but I don't see the point of keeping
>     redundant information like that.  Also, it the comment describes
>     some of the fields that were moved to ConstMethod years ago.   I
>     don't think you want to try to correct these things with this typo
>     change, but we should (I could) file an RFE to correct them later.
>
>     thanks,
>     Coleen
>
>
>     On 01/14/2014 12:53 PM, Krystal Mok wrote:
>>     Hi Jesper,
>>
>>     That looks fine to me. Thank you!
>>     It's still better if someone from the runtime team could verify
>>     the change in oops/method.hpp, and someone from the compiler team
>>     could verify the change in ci/ciField.hpp|cpp
>>
>>     Thanks,
>>     Kris
>>
>>
>>     On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson
>>     <jesper.wilhelmsson at oracle.com
>>     <mailto:jesper.wilhelmsson at oracle.com>> wrote:
>>
>>         Sure, no problem. Webrev is updated, please verify.
>>         I took the liberty of changing the layout of the comment in
>>         ciField.cpp. Since there was only one case left it didn't
>>         feel motivated to have a list of cases.
>>         /Jesper
>>
>>         Krystal Mok skrev 13/1/14 7:36 PM:
>>
>>             Hi Jesper,
>>
>>             Thanks! I took a look and the change was fine.
>>
>>             I do have a couple of other comment fixes that I'd like
>>             to hitchhike:
>>
>>             1. oops/method.hpp
>>
>>             The comments say ConstMethod* and MethodData* are oops,
>>             which they aren't anymore.
>>             I'm not sure if the wording for "putting oops and
>>             method_size first for better
>>             gc cache locality" still matters. It probably doesn't
>>             matter anymore, since GC
>>             doesn't have to mark through these fields with the
>>             PermGen removal.
>>
>>             2. ci/ciField.hpp, ci/ciField.cpp
>>
>>             The comments say in order to consider a field as a
>>             constant, it cannot hold an
>>             non-perm-space oop. I believe this limitation has been
>>             removed. Could someone
>>             from the compiler team verify if that's true?
>>
>>             The diff is at the end of this mail.
>>
>>             Thanks,
>>             Kris
>>
>>             diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
>>             --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013
>>             -0800
>>             +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014
>>             -0800
>>
>>             @@ -202,13 +202,9 @@
>>                   }
>>                   // This field just may be constant.  The only cases
>>             where it will
>>             -    // not be constant are:
>>             +    // not be constant is:
>>                   //
>>             -    // 1. The field holds a non-perm-space oop.  The
>>             field is, strictly
>>             -    //    speaking, constant but we cannot embed
>>             non-perm-space oops into
>>             -    //    generated code.  For the time being we need to
>>             consider the
>>             -    //    field to be not constant.
>>             -    // 2. The field is a *special* static&final field
>>             whose value
>>             +    // 1. The field is a *special* static&final field
>>             whose value
>>                   //    may change.  The three examples are
>>             java.lang.System.in <http://java.lang.System.in>
>>             <http://java.lang.System.in>,
>>
>>                   //    java.lang.System.out, and java.lang.System.err.
>>             diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
>>             --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013
>>             -0800
>>             +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014
>>             -0800
>>
>>             @@ -130,9 +130,7 @@
>>                 //   1. The field is both static and final
>>                 //   2. The canonical holder of the field has undergone
>>                 //      static initialization.
>>             -  //   3. If the field is an object or array, then the oop
>>             -  //      in question is allocated in perm space.
>>             -  //   4. The field is not one of the special static/final
>>             +  //   3. The field is not one of the special static/final
>>                 //      non-constant fields.  These are
>>             java.lang.System.in <http://java.lang.System.in>
>>             <http://java.lang.System.in>
>>
>>                 //      and java.lang.System.out.  Abomination.
>>                 //
>>             diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
>>             --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07
>>             2013 -0800
>>             +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17
>>             2014 -0800
>>
>>             @@ -38,13 +38,11 @@
>>               #include "utilities/accessFlags.hpp"
>>               #include "utilities/growableArray.hpp"
>>             -// A Method* represents a Java method.
>>             +// A Method represents a Java method.
>>               //
>>               // Memory layout (each line represents a word). Note
>>             that most applications
>>             load thousands of methods,
>>               // so keeping the size of this structure small has a
>>             big impact on footprint.
>>               //
>>             -// We put all oops and method_size first for better gc
>>             cache locality.
>>             -//
>>               // The actual bytecodes are inlined after the end of
>>             the Method struct.
>>               //
>>               // There are bits in the access_flags telling whether
>>             inlined tables are present.
>>             @@ -64,17 +62,17 @@
>>               // | header                     |
>>               // | klass                    |
>>               // |------------------------------------------------------|
>>             -// | ConstMethod* (oop)                 |
>>             +// | ConstMethod* (metadata)            |
>>               // |------------------------------------------------------|
>>             -// | methodData (oop)                 |
>>             -// | methodCounters                   |
>>             +// | MethodData*  (metadata)            |
>>             +// | MethodCounters                   |
>>               // |------------------------------------------------------|
>>               // | access_flags                     |
>>               // | vtable_index                     |
>>               // |------------------------------------------------------|
>>               // | result_index (C++ interpreter only)                  |
>>               // |------------------------------------------------------|
>>             -// | method_size             | intrinsic_id|   flags    |
>>             +// | method_size             | intrinsic_id  |   flags    |
>>               // |------------------------------------------------------|
>>               // | code (pointer)             |
>>               // | i2i  (pointer)             |
>>
>>
>>
>>
>>             On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson
>>             <jesper.wilhelmsson at oracle.com
>>             <mailto:jesper.wilhelmsson at oracle.com>
>>             <mailto:jesper.wilhelmsson at oracle.com
>>             <mailto:jesper.wilhelmsson at oracle.com>>> wrote:
>>
>>                 Hi Kris!
>>
>>                 No problem, I'll add it to the change. Please verify
>>             that it looks OK in the
>>                 updated webrev (same link as before).
>>
>>             http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>             <http://cr.openjdk.java.net/%7E__jwilhelm/8025856/webrev.1/>
>>
>>                
>>             <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>             <http://cr.openjdk.java.net/%7Ejwilhelm/8025856/webrev.1/>>
>>
>>                 /Jesper
>>
>>
>>                 Krystal Mok skrev 10/1/14 7:17 PM:
>>
>>                     Hi Jesper,
>>
>>                     Nice to see cleaner code!
>>
>>                     Hitchhike: It'd be nice if you could include this
>>             typo in:
>>             http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html
>>
>>
>>                    
>>             <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html>
>>                     I didn't really like sending one-liner comment
>>             typo fix anyway...with a
>>                     lot of
>>                     other typos, the story is different ;-)
>>
>>                     Thanks,
>>                     Kris
>>
>>
>>
>>                     On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore
>>                     <coleen.phillimore at oracle.com
>>             <mailto:coleen.phillimore at oracle.com>
>>             <mailto:coleen.phillimore at oracle.com
>>             <mailto:coleen.phillimore at oracle.com>>
>>                     <mailto:coleen.phillimore@
>>             <mailto:coleen.phillimore@>__oracle.com <http://oracle.com>
>>
>>                     <mailto:coleen.phillimore at oracle.com
>>             <mailto:coleen.phillimore at oracle.com>>>> wrote:
>>
>>                          Seems fine with me also.  Could you find
>>             typos in the comments in the
>>                          runtime code "by accident" too? :)
>>                          thanks,
>>                          Coleen
>>
>>
>>                          On 1/10/2014 10:39 AM, Daniel D. Daugherty
>>             wrote:
>>
>>                              On 1/10/14 5:49 AM, Jesper Wilhelmsson
>>             wrote:
>>
>>                                  Hi,
>>
>>                                  I have a change out for review that
>>             fixes a huge pile of
>>                     typos in
>>                                  the comments in the GC code. The RFR
>>             was sent to the GC
>>                     list, but I
>>                                  want to give a heads up in case
>>             anyone else is changing GC
>>                     code and
>>                                  want to avoid merge conflicts.
>>
>>                                  The patch:
>>             http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ <http://cr.openjdk.java.net/%7E____jwilhelm/8025856/webrev.1/>
>>                    
>>             <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>             <http://cr.openjdk.java.net/%7E__jwilhelm/8025856/webrev.1/>>
>>
>>
>>
>>                                
>>              <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ <http://cr.openjdk.java.net/%7E__jwilhelm/8025856/webrev.1/>
>>                    
>>             <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>             <http://cr.openjdk.java.net/%7Ejwilhelm/8025856/webrev.1/>>>
>>
>>
>>                                  There are also a few files where I
>>             happened to find a few
>>                     typos "by
>>                                  accident" in code that is not
>>             strictly GC code. These are:
>>
>>              src/share/vm/memory/heap.cpp
>>              src/share/vm/memory/heap.hpp
>>              src/share/vm/memory/____allocation.hpp
>>              src/share/vm/memory/____resourceArea.hpp
>>              src/share/vm/runtime/thread.____cpp
>>
>>
>>
>>                                  There is a total of eight typos
>>             fixed in these files so I
>>                     think the
>>                                  risk of merge conflicts here is
>>             minimal. Are there any
>>                     objections to
>>                                  including these fixes in the change?
>>
>>
>>                              Vote: go for it!
>>
>>                              Dan
>>
>>
>>                                  Thanks,
>>                                  /Jesper
>>
>>
>>
>>
>>
>>
>
>


From rednaxelafx at gmail.com  Tue Jan 14 15:21:36 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Wed, 15 Jan 2014 07:21:36 +0800
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52D5A0D6.3090602@oracle.com>
References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com>
	<52D017CE.6090509@oracle.com>
	<CA+cQ+tQ6b2iw06tcf0n0-R=m=cnJ2YnRdR+64dD6wEd2B4OVWw@mail.gmail.com>
	<52D3E50E.5040308@oracle.com>
	<CA+cQ+tRoJ2ujyXGEgDYkC6xah3VRdDzyN8rR15SV05J1wni+QQ@mail.gmail.com>
	<52D53DBF.9040500@oracle.com>
	<CA+cQ+tS+hytNx55hazNTPDHQ1qrnx=-QYGp_hCM=f84bCaZ2EQ@mail.gmail.com>
	<52D5860C.4010107@oracle.com>
	<CA+cQ+tRPJs+YWhDh9Nf-7GvzVzgseVwLiYv4Z81=qiyBjfq88A@mail.gmail.com>
	<52D5A0D6.3090602@oracle.com>
Message-ID: <CA+cQ+tTFUZUcwyh3um=9fJLZDuFq_7QyBJHQiT_US3eRc7yCAg@mail.gmail.com>

No problem with that either. :-)
Thanks, Coleen!

- Kris


On Wed, Jan 15, 2014 at 4:40 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
> On 01/14/2014 02:29 PM, Krystal Mok wrote:
>
> Hi Coleen,
>
>  Thanks for the review. I'm all for getting things right, and I agree
> there's more comments that needs some love.
> I'm okay with leaving the changes in method.hpp out for now, and correct
> them later.
>
>
> The ones you and Jesper have so far are fine.  You can leave them in.   I
> would like you to leave them in.   I was only pointing out that there are
> more changes needed that could be done by themselves later.
>
> Coleen
>
>
>
>  Thanks,
> Kris
>
>
> On Wed, Jan 15, 2014 at 2:46 AM, Coleen Phillimore <
> coleen.phillimore at oracle.com> wrote:
>
>>
>> These changes you have look good for Method except a lot of the comment
>> is out of date.  The block comment about the layout of fields in Method is
>> redundant with the actual declaration and wrong.  It's a nice visual but I
>> don't see the point of keeping redundant information like that.  Also, it
>> the comment describes some of the fields that were moved to ConstMethod
>> years ago.   I don't think you want to try to correct these things with
>> this typo change, but we should (I could) file an RFE to correct them later.
>>
>> thanks,
>> Coleen
>>
>>
>> On 01/14/2014 12:53 PM, Krystal Mok wrote:
>>
>> Hi Jesper,
>>
>>  That looks fine to me. Thank you!
>> It's still better if someone from the runtime team could verify the
>> change in oops/method.hpp, and someone from the compiler team could verify
>> the change in ci/ciField.hpp|cpp
>>
>>  Thanks,
>> Kris
>>
>>
>> On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson <
>> jesper.wilhelmsson at oracle.com> wrote:
>>
>>> Sure, no problem. Webrev is updated, please verify.
>>> I took the liberty of changing the layout of the comment in ciField.cpp.
>>> Since there was only one case left it didn't feel motivated to have a list
>>> of cases.
>>> /Jesper
>>>
>>> Krystal Mok skrev 13/1/14 7:36 PM:
>>>
>>>>  Hi Jesper,
>>>>
>>>> Thanks! I took a look and the change was fine.
>>>>
>>>> I do have a couple of other comment fixes that I'd like to hitchhike:
>>>>
>>>> 1. oops/method.hpp
>>>>
>>>> The comments say ConstMethod* and MethodData* are oops, which they
>>>> aren't anymore.
>>>> I'm not sure if the wording for "putting oops and method_size first for
>>>> better
>>>> gc cache locality" still matters. It probably doesn't matter anymore,
>>>> since GC
>>>> doesn't have to mark through these fields with the PermGen removal.
>>>>
>>>> 2. ci/ciField.hpp, ci/ciField.cpp
>>>>
>>>> The comments say in order to consider a field as a constant, it cannot
>>>> hold an
>>>> non-perm-space oop. I believe this limitation has been removed. Could
>>>> someone
>>>> from the compiler team verify if that's true?
>>>>
>>>> The diff is at the end of this mail.
>>>>
>>>> Thanks,
>>>> Kris
>>>>
>>>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp
>>>>  --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800
>>>> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800
>>>>
>>>> @@ -202,13 +202,9 @@
>>>>       }
>>>>       // This field just may be constant.  The only cases where it will
>>>> -    // not be constant are:
>>>> +    // not be constant is:
>>>>       //
>>>> -    // 1. The field holds a non-perm-space oop.  The field is, strictly
>>>> -    //    speaking, constant but we cannot embed non-perm-space oops
>>>> into
>>>> -    //    generated code.  For the time being we need to consider the
>>>> -    //    field to be not constant.
>>>> -    // 2. The field is a *special* static&final field whose value
>>>> +    // 1. The field is a *special* static&final field whose value
>>>>       //    may change.  The three examples are java.lang.System.in
>>>>  <http://java.lang.System.in>,
>>>>
>>>>       //    java.lang.System.out, and java.lang.System.err.
>>>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp
>>>>  --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800
>>>> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800
>>>>
>>>> @@ -130,9 +130,7 @@
>>>>     //   1. The field is both static and final
>>>>     //   2. The canonical holder of the field has undergone
>>>>     //      static initialization.
>>>> -  //   3. If the field is an object or array, then the oop
>>>> -  //      in question is allocated in perm space.
>>>> -  //   4. The field is not one of the special static/final
>>>> +  //   3. The field is not one of the special static/final
>>>>     //      non-constant fields.  These are java.lang.System.in
>>>>  <http://java.lang.System.in>
>>>>
>>>>     //      and java.lang.System.out.  Abomination.
>>>>     //
>>>> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp
>>>>  --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800
>>>> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800
>>>>
>>>> @@ -38,13 +38,11 @@
>>>>   #include "utilities/accessFlags.hpp"
>>>>   #include "utilities/growableArray.hpp"
>>>> -// A Method* represents a Java method.
>>>> +// A Method represents a Java method.
>>>>   //
>>>>   // Memory layout (each line represents a word). Note that most
>>>> applications
>>>> load thousands of methods,
>>>>   // so keeping the size of this structure small has a big impact on
>>>> footprint.
>>>>   //
>>>> -// We put all oops and method_size first for better gc cache locality.
>>>> -//
>>>>   // The actual bytecodes are inlined after the end of the Method
>>>> struct.
>>>>   //
>>>>   // There are bits in the access_flags telling whether inlined tables
>>>> are present.
>>>> @@ -64,17 +62,17 @@
>>>>   // | header                                               |
>>>>   // | klass                                                |
>>>>   // |------------------------------------------------------|
>>>> -// | ConstMethod*                   (oop)                 |
>>>> +// | ConstMethod*                   (metadata)            |
>>>>   // |------------------------------------------------------|
>>>> -// | methodData                     (oop)                 |
>>>> -// | methodCounters                                       |
>>>> +// | MethodData*                    (metadata)            |
>>>> +// | MethodCounters                                       |
>>>>   // |------------------------------------------------------|
>>>>   // | access_flags                                         |
>>>>   // | vtable_index                                         |
>>>>   // |------------------------------------------------------|
>>>>   // | result_index (C++ interpreter only)                  |
>>>>   // |------------------------------------------------------|
>>>> -// | method_size             |   intrinsic_id|   flags    |
>>>> +// | method_size             | intrinsic_id  |   flags    |
>>>>   // |------------------------------------------------------|
>>>>   // | code                           (pointer)             |
>>>>   // | i2i                            (pointer)             |
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson
>>>>   <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com>>
>>>> wrote:
>>>>
>>>>     Hi Kris!
>>>>
>>>>     No problem, I'll add it to the change. Please verify that it looks
>>>> OK in the
>>>>     updated webrev (same link as before).
>>>>
>>>>      http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>>>
>>>>     <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>
>>>>
>>>>     /Jesper
>>>>
>>>>
>>>>     Krystal Mok skrev 10/1/14 7:17 PM:
>>>>
>>>>         Hi Jesper,
>>>>
>>>>         Nice to see cleaner code!
>>>>
>>>>         Hitchhike: It'd be nice if you could include this typo in:
>>>>
>>>> http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html
>>>>
>>>>         <
>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html
>>>> >
>>>>         I didn't really like sending one-liner comment typo fix
>>>> anyway...with a
>>>>         lot of
>>>>         other typos, the story is different ;-)
>>>>
>>>>         Thanks,
>>>>         Kris
>>>>
>>>>
>>>>
>>>>         On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore
>>>>         <coleen.phillimore at oracle.com <mailto:
>>>> coleen.phillimore at oracle.com>
>>>>          <mailto:coleen.phillimore at __oracle.com
>>>>
>>>>         <mailto:coleen.phillimore at oracle.com>>> wrote:
>>>>
>>>>              Seems fine with me also.  Could you find typos in the
>>>> comments in the
>>>>              runtime code "by accident" too? :)
>>>>              thanks,
>>>>              Coleen
>>>>
>>>>
>>>>              On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>>
>>>>                  On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>>
>>>>                      Hi,
>>>>
>>>>                      I have a change out for review that fixes a huge
>>>> pile of
>>>>         typos in
>>>>                      the comments in the GC code. The RFR was sent to
>>>> the GC
>>>>         list, but I
>>>>                      want to give a heads up in case anyone else is
>>>> changing GC
>>>>         code and
>>>>                      want to avoid merge conflicts.
>>>>
>>>>                      The patch:
>>>>          http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/
>>>>         <http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/>
>>>>
>>>>
>>>>                      <
>>>> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/
>>>>         <http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/>>
>>>>
>>>>
>>>>                      There are also a few files where I happened to
>>>> find a few
>>>>         typos "by
>>>>                      accident" in code that is not strictly GC code.
>>>> These are:
>>>>
>>>>                      src/share/vm/memory/heap.cpp
>>>>                      src/share/vm/memory/heap.hpp
>>>>                       src/share/vm/memory/____allocation.hpp
>>>>                      src/share/vm/memory/____resourceArea.hpp
>>>>                      src/share/vm/runtime/thread.____cpp
>>>>
>>>>
>>>>
>>>>                      There is a total of eight typos fixed in these
>>>> files so I
>>>>         think the
>>>>                      risk of merge conflicts here is minimal. Are there
>>>> any
>>>>         objections to
>>>>                      including these fixes in the change?
>>>>
>>>>
>>>>                  Vote: go for it!
>>>>
>>>>                  Dan
>>>>
>>>>
>>>>                      Thanks,
>>>>                      /Jesper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>

From david.holmes at oracle.com  Tue Jan 14 16:55:28 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Jan 2014 10:55:28 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
Message-ID: <52D5DC80.1040003@oracle.com>

Hi Goetz,

Sorry for the delay in getting back to this.

The general changes to the volatile barriers to support IRIW are okay. 
The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more 
specifically it is 
not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of 
the commentary excessive, particularly for shared code. In particular 
the IRIW example in parse3.cpp - it seems a strange place to give the 
explanation and I don't think we need it to that level of detail. Seems 
to me that is present is globalDefinitions_ppc.hpp is quite adequate.

The changes related to volatile writes in the constructor, as discussed 
are not required by the Java Memory Model. If you want to keep these 
then I think they should all be guarded with PPC64 because it is not 
related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the 
PPC64 porters.

Thanks,
David

On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I updated this webrev.  I detected a small flaw I made when editing this version.
> The #endif in line 322, parse3.cpp was in the wrong line.
> I also based the webrev on the latest version of the stage repo.
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Freitag, 20. Dezember 2013 13:47
> To: David Holmes
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi David,
>
>> So we can at least undo #4 now we have established those tests were not
>> required to pass.
> We would prefer if we could keep this in.  We want to avoid that it's
> blamed on the VM if java programs are failing on PPC after they worked
> on x86.  To clearly mark it as overfulfilling the spec I would guard it by
> a flag as proposed.  But if you insist I will remove it.  Also, this part is
> not that performance relevant.
>
>> A compile-time guard (ifdef) would be better than a runtime one I think
> I added a compile-time guard in this new webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
> several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC)
> but this way I only have to change the ppc platform.
>
> Best regards,
>    Goetz
>
> P.S.:  I will also be available over the Christmas period.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Freitag, 20. Dezember 2013 05:58
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Sorry for the delay, it takes a while to catch up after two weeks
> vacation :) Next vacation (ie next two weeks) I'll continue to check emails.
>
> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> ok, I understand the tests are wrong.  It's good this issue is settled.
>> Thanks Aleksey and Andreas for going into the details of the proof!
>>
>> About our change:  David, the causality is the other way round.
>> The change is about IRIW.
>> 1. To pass IRIW, we must use sync instructions before loads.
>
> This is the part I still have some question marks over as the
> implications are not nice for performance on non-TSO platforms. But I'm
> no further along in processing that paper I'm afraid.
>
>> 2. If we do syncs before loads, we don't need to do them after stores.
>> 3. If we don't do them after stores, we fail the volatile constructor tests.
>> 4. So finally we added them again at the end of the constructor after stores
>>        to pass the volatile constructor tests.
>
> So we can at least undo #4 now we have established those tests were not
> required to pass.
>
>> We originally passed the constructor tests because the ppc memory order
>> instructions are not as find-granular as the
>> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
>> MemBarVolatile after the store fixes the constructor tests.  The proper representation
>> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
>> anyways.
>>
>>> I'm not happy with the ifdef approach but I won't block it.
>> I'd be happy to add a property
>>     OrderAccess::cpu_is_multiple_copy_atomic()
>
> A compile-time guard (ifdef) would be better than a runtime one I think
> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
> based not architecture based) as that will allows for turning this
> on/off for any architecture for testing purposes.
>
> Thanks,
> David
>
>> or the like to guard the customization.  I'd like that much better. Or also
>>      OrderAccess::needs_support_iriw_ordering()
>>      VM_Version::needs_support_iriw_ordering()
>>
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 28. November 2013 00:34
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> TL;DR version:
>>
>> Discussion on the c-i list has now confirmed that a constructor-barrier
>> for volatiles is not required as part of the JMM specification. It *may*
>> be required in an implementation that doesn't pre-zero memory to ensure
>> you can't see uninitialized fields. So the tests for this are invalid
>> and this part of the patch is not needed in general (ppc64 may need it
>> due to other factors).
>>
>> Re: "multiple copy atomicity" - first thanks for correcting the term :)
>> Second thanks for the reference to that paper! For reference:
>>
>> "The memory system (perhaps involving a hierarchy of buffers and a
>> complex interconnect) does not guarantee that a write becomes visible to
>> all other hardware threads at the same time point; these architectures
>> are not multiple-copy atomic."
>>
>> This is the visibility issue that I referred to and affects both ARM and
>> PPC. But of course it is normally handled by using suitable barriers
>> after the stores that need to be visible. I think the crux of the
>> current issue is what you wrote below:
>>
>>    > The fixes for the constructor issue are only needed because we
>>    > remove the sync instruction from behind stores (parse3.cpp:320)
>>    > and place it before loads.
>>
>> I hadn't grasped this part. Obviously if you fail to do the sync after
>> the store then you have to do something around the loads to get the same
>> results! I still don't know what lead you to the conclusion that the
>> only way to fix the IRIW issue was to put the fence before the load -
>> maybe when I get the chance to read that paper in full it will be clearer.
>>
>> So ... the basic problem is that the current structure in the VM has
>> hard-wired one choice of how to get the right semantics for volatile
>> variables. You now want to customize that but not all the requisite
>> hooks are present. It would be better if volatile_load and
>> volatile_store were factored out so that they could be implemented as
>> desired per-platform. Alternatively there could be pre- and post- hooks
>> that could then be customized per platform. Otherwise you need
>> platform-specific ifdef's to handle it as per your patch.
>>
>> I'm not happy with the ifdef approach but I won't block it. I think this
>> is an area where a lot of clean up is needed in the VM. The barrier
>> abstractions are a confused mess in my opinion.
>>
>> Thanks,
>> David
>> -----
>>
>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>
>>> I did not yet add the
>>>       OrderAccess::needs_support_iriw_ordering()
>>>       VM_Version::needs_support_iriw_ordering()
>>> or
>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>> to reduce #defined, as I got no further comment on that.
>>>
>>>
>>> WRT to the validity of the tests and the interpretation of the JMM
>>> I feel not in the position to contribute substantially.
>>>
>>> But we would like to pass the torture test suite as we consider
>>> this a substantial task in implementing a PPC port.  Also we think
>>> both tests show behavior a programmer would expect.  It's bad if
>>> Java code runs fine on the more common x86 platform, and then
>>> fails on ppc.  This will always first be blamed on the VM.
>>>
>>> The fixes for the constructor issue are only needed because we
>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>> and place it before loads.  Then there is no sync between volatile store
>>> and publishing the object.  So we add it again in this one case
>>> (volatile store in constructor).
>>>
>>>
>>> @David
>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>> and that's being discussed now for almost a year.
>>>> It may have started a year ago but work on it has hardly been continuous.
>>> That's not true, we did a lot of investigation and testing on this issue.
>>> And we came up with a solution we consider the best possible. If you
>>> have objections, you should at least give the draft of a better solution,
>>> we would volunteer to implement and test it.
>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>
>>> @David
>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>> can't find any reference to it.
>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>
>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>>
>>> Best regards and thanks for all your involvements,
>>>      Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Mittwoch, 27. November 2013 12:53
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>> Hi David,
>>>>
>>>> -- Volatile in constuctor
>>>>> AFAIK we have not seen those tests fail due to a
>>>>> missing constructor barrier.
>>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>
>>> And see follow ups - the tests are invalid.
>>>
>>>> -- IRIW issue
>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>> moments thought.
>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>> and that's being discussed now for almost a year.
>>>
>>> It may have started a year ago but work on it has hardly been continuous.
>>>
>>>>> You are implying there is a problem here that will
>>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>>> (I don't really know about ARM, though).
>>>> So if I can write down a nicer solution testing for methods that are evaluated
>>>> by the C-compiler I'm happy.
>>>>
>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>> is that
>>>>       store
>>>>       sync
>>>> does not assure multiple-read-atomicity,
>>>> only
>>>>       sync
>>>>       load
>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>> pass that test.
>>>
>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>> can't find any reference to it.
>>>
>>> Thanks,
>>> David
>>>
>>>       The JMM is fine. And
>>>>       store
>>>>       MemBarVolatile
>>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>>> do what is required.
>>>>
>>>> So if you are off soon, please let's come to a solution that
>>>> might be improvable in the way it's implemented, but that
>>>> allows us to implement a correct PPC64 port.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>> Hi everybody,
>>>>>
>>>>> thanks a lot for the detailed reviews!
>>>>> I'll try to answer to all in one mail.
>>>>>
>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>>> We don't think it's correct if we omit the barrier after initializing
>>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>>> and Doug Lea, and they agreed.
>>>>> Also, concurrency torture tests
>>>>>         LongVolatileTest
>>>>>         AtomicIntegerInitialValueTest
>>>>> will fail.
>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>>
>>>> The affects of unsafe publication are always surprising - volatiles do
>>>> not add anything special here. AFAIK there is nothing in the JMM that
>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>> missing constructor barrier.
>>>>
>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>>> see a way to implement this cheaper.
>>>>>
>>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>>> Basically, I agree on this.  But you also have to take into account
>>>>> that due to the different memory ordering instructions on different platforms
>>>>> just implementing something empty is not sufficient.
>>>>> An example:
>>>>>        MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>        MemBarVolatile    // means  StoreLoad barrier
>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>        MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>>        MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>> Just doing what is required.
>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>> fine grained operations:
>>>>>         MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>>        MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>>> MemBarRelease empty, as it is also used independently.
>>>>>
>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>
>>>>> I would propose to guard the code by
>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>> Else, David, how would you propose to implement this platform independent?
>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>
>>>> I can not possibly answer to the necessary level of detail with a few
>>>> moments thought. You are implying there is a problem here that will
>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>> different?) and I can not take that on face value at the moment. The
>>>> only reason I can see IRIW not being handled by the JMM requirements for
>>>> volatile accesses is if there are global visibility issues that are not
>>>> addressed - but even then I would expect heavy barriers at the store
>>>> would deal with that, not at the load. (This situation reminds me of the
>>>> need for read-barriers on Alpha architecture due to the use of software
>>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>>> that on ppc!)
>>>>
>>>> Sorry - There is no quick resolution here and in a couple of days I will
>>>> be heading out on vacation for two weeks.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>> -- Other ports:
>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>
>>>>> -- MemBarStoreStore after initialization
>>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>>> prepare an extra webrev for hotspot-comp.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>> To: Vladimir Kozlov
>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>>
>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>> I have to ask David to do correctness evaluation.
>>>>>
>>>>>       From what I understand what we see here is an attempt to fix an
>>>>> existing issue with the implementation of volatiles so that the IRIW
>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>>> load.
>>>>>
>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>> happy to let them do whatever they like (surely this kills performance
>>>>> though!). But I do not agree with the changes to the shared code that
>>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>>> polluting the shared code. My concern is similar to what I said with the
>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>> given architecture then the implementation in OrderAccess should reduce
>>>>> to a no-op.
>>>>>
>>>>> And as Vitaly points out the constructor barriers are not needed under
>>>>> the JMM.
>>>>>
>>>>>> I am fine with suggested changes because you did not change our current
>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>> But may be it should be done using more general query which is set
>>>>>> depending on platform:
>>>>>>
>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>
>>>>>> or similar to what we use now:
>>>>>>
>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>
>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>> Memory Model, there should not be any need to call this out explicitly
>>>>> like this.
>>>>>
>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>>       From what I understand our ppc port is also affected. David?
>>>>>
>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>>
>>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>
>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>
>>>>>>          if (is_vol) {
>>>>>>            // See comment in do_get_xxx().
>>>>>> #ifndef PPC64
>>>>>>            insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>> #else
>>>>>>            if (is_field) {
>>>>>>              // Add MemBarRelease for constructors which write volatile field
>>>>>> (PPC64).
>>>>>>              set_wrote_volatile(true);
>>>>>>            }
>>>>>> #endif
>>>>>>          }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>>> the torture test suite:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>
>>>>>>> Example:
>>>>>>> volatile x=0, y=0
>>>>>>>         __________    __________    __________    __________
>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>
>>>>>>>          write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>                        read(y)                     read(x)
>>>>>>>
>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>
>>>>>>>
>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>
>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>
>>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>>> written in constructors are visible before the reference gets
>>>>>>> published.
>>>>>>>
>>>>>>>
>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>>> strong.
>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Please review and test this change.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>         Goetz.
>>>>>>>

From goetz.lindenmaier at sap.com  Wed Jan 15 07:28:15 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 15 Jan 2014 15:28:15 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52D5DC80.1040003@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>

Hi David, 

I updated the webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/

- I removed the IRIW example in parse3.cpp
- I adapted the comments not to point to that comment, and to 
  reflect the new flagging.  Also I mention that we support the
  volatile constructor issue, but that it's not standard.
- I protected issuing the barrier for the constructor by PPC64.
  I also think it's better to separate these this way.

Thanks for your comments!

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Mittwoch, 15. Januar 2014 01:55
To: Lindenmaier, Goetz
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Hi Goetz,

Sorry for the delay in getting back to this.

The general changes to the volatile barriers to support IRIW are okay. 
The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more 
specifically it is 
not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of 
the commentary excessive, particularly for shared code. In particular 
the IRIW example in parse3.cpp - it seems a strange place to give the 
explanation and I don't think we need it to that level of detail. Seems 
to me that is present is globalDefinitions_ppc.hpp is quite adequate.

The changes related to volatile writes in the constructor, as discussed 
are not required by the Java Memory Model. If you want to keep these 
then I think they should all be guarded with PPC64 because it is not 
related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the 
PPC64 porters.

Thanks,
David

On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I updated this webrev.  I detected a small flaw I made when editing this version.
> The #endif in line 322, parse3.cpp was in the wrong line.
> I also based the webrev on the latest version of the stage repo.
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Freitag, 20. Dezember 2013 13:47
> To: David Holmes
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi David,
>
>> So we can at least undo #4 now we have established those tests were not
>> required to pass.
> We would prefer if we could keep this in.  We want to avoid that it's
> blamed on the VM if java programs are failing on PPC after they worked
> on x86.  To clearly mark it as overfulfilling the spec I would guard it by
> a flag as proposed.  But if you insist I will remove it.  Also, this part is
> not that performance relevant.
>
>> A compile-time guard (ifdef) would be better than a runtime one I think
> I added a compile-time guard in this new webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
> several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC)
> but this way I only have to change the ppc platform.
>
> Best regards,
>    Goetz
>
> P.S.:  I will also be available over the Christmas period.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Freitag, 20. Dezember 2013 05:58
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Sorry for the delay, it takes a while to catch up after two weeks
> vacation :) Next vacation (ie next two weeks) I'll continue to check emails.
>
> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> ok, I understand the tests are wrong.  It's good this issue is settled.
>> Thanks Aleksey and Andreas for going into the details of the proof!
>>
>> About our change:  David, the causality is the other way round.
>> The change is about IRIW.
>> 1. To pass IRIW, we must use sync instructions before loads.
>
> This is the part I still have some question marks over as the
> implications are not nice for performance on non-TSO platforms. But I'm
> no further along in processing that paper I'm afraid.
>
>> 2. If we do syncs before loads, we don't need to do them after stores.
>> 3. If we don't do them after stores, we fail the volatile constructor tests.
>> 4. So finally we added them again at the end of the constructor after stores
>>        to pass the volatile constructor tests.
>
> So we can at least undo #4 now we have established those tests were not
> required to pass.
>
>> We originally passed the constructor tests because the ppc memory order
>> instructions are not as find-granular as the
>> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
>> MemBarVolatile after the store fixes the constructor tests.  The proper representation
>> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
>> anyways.
>>
>>> I'm not happy with the ifdef approach but I won't block it.
>> I'd be happy to add a property
>>     OrderAccess::cpu_is_multiple_copy_atomic()
>
> A compile-time guard (ifdef) would be better than a runtime one I think
> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
> based not architecture based) as that will allows for turning this
> on/off for any architecture for testing purposes.
>
> Thanks,
> David
>
>> or the like to guard the customization.  I'd like that much better. Or also
>>      OrderAccess::needs_support_iriw_ordering()
>>      VM_Version::needs_support_iriw_ordering()
>>
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 28. November 2013 00:34
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> TL;DR version:
>>
>> Discussion on the c-i list has now confirmed that a constructor-barrier
>> for volatiles is not required as part of the JMM specification. It *may*
>> be required in an implementation that doesn't pre-zero memory to ensure
>> you can't see uninitialized fields. So the tests for this are invalid
>> and this part of the patch is not needed in general (ppc64 may need it
>> due to other factors).
>>
>> Re: "multiple copy atomicity" - first thanks for correcting the term :)
>> Second thanks for the reference to that paper! For reference:
>>
>> "The memory system (perhaps involving a hierarchy of buffers and a
>> complex interconnect) does not guarantee that a write becomes visible to
>> all other hardware threads at the same time point; these architectures
>> are not multiple-copy atomic."
>>
>> This is the visibility issue that I referred to and affects both ARM and
>> PPC. But of course it is normally handled by using suitable barriers
>> after the stores that need to be visible. I think the crux of the
>> current issue is what you wrote below:
>>
>>    > The fixes for the constructor issue are only needed because we
>>    > remove the sync instruction from behind stores (parse3.cpp:320)
>>    > and place it before loads.
>>
>> I hadn't grasped this part. Obviously if you fail to do the sync after
>> the store then you have to do something around the loads to get the same
>> results! I still don't know what lead you to the conclusion that the
>> only way to fix the IRIW issue was to put the fence before the load -
>> maybe when I get the chance to read that paper in full it will be clearer.
>>
>> So ... the basic problem is that the current structure in the VM has
>> hard-wired one choice of how to get the right semantics for volatile
>> variables. You now want to customize that but not all the requisite
>> hooks are present. It would be better if volatile_load and
>> volatile_store were factored out so that they could be implemented as
>> desired per-platform. Alternatively there could be pre- and post- hooks
>> that could then be customized per platform. Otherwise you need
>> platform-specific ifdef's to handle it as per your patch.
>>
>> I'm not happy with the ifdef approach but I won't block it. I think this
>> is an area where a lot of clean up is needed in the VM. The barrier
>> abstractions are a confused mess in my opinion.
>>
>> Thanks,
>> David
>> -----
>>
>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>
>>> I did not yet add the
>>>       OrderAccess::needs_support_iriw_ordering()
>>>       VM_Version::needs_support_iriw_ordering()
>>> or
>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>> to reduce #defined, as I got no further comment on that.
>>>
>>>
>>> WRT to the validity of the tests and the interpretation of the JMM
>>> I feel not in the position to contribute substantially.
>>>
>>> But we would like to pass the torture test suite as we consider
>>> this a substantial task in implementing a PPC port.  Also we think
>>> both tests show behavior a programmer would expect.  It's bad if
>>> Java code runs fine on the more common x86 platform, and then
>>> fails on ppc.  This will always first be blamed on the VM.
>>>
>>> The fixes for the constructor issue are only needed because we
>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>> and place it before loads.  Then there is no sync between volatile store
>>> and publishing the object.  So we add it again in this one case
>>> (volatile store in constructor).
>>>
>>>
>>> @David
>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>> and that's being discussed now for almost a year.
>>>> It may have started a year ago but work on it has hardly been continuous.
>>> That's not true, we did a lot of investigation and testing on this issue.
>>> And we came up with a solution we consider the best possible. If you
>>> have objections, you should at least give the draft of a better solution,
>>> we would volunteer to implement and test it.
>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>
>>> @David
>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>> can't find any reference to it.
>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>
>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>>
>>> Best regards and thanks for all your involvements,
>>>      Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Mittwoch, 27. November 2013 12:53
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>> Hi David,
>>>>
>>>> -- Volatile in constuctor
>>>>> AFAIK we have not seen those tests fail due to a
>>>>> missing constructor barrier.
>>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>
>>> And see follow ups - the tests are invalid.
>>>
>>>> -- IRIW issue
>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>> moments thought.
>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>> and that's being discussed now for almost a year.
>>>
>>> It may have started a year ago but work on it has hardly been continuous.
>>>
>>>>> You are implying there is a problem here that will
>>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>>> (I don't really know about ARM, though).
>>>> So if I can write down a nicer solution testing for methods that are evaluated
>>>> by the C-compiler I'm happy.
>>>>
>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>> is that
>>>>       store
>>>>       sync
>>>> does not assure multiple-read-atomicity,
>>>> only
>>>>       sync
>>>>       load
>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>> pass that test.
>>>
>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>> can't find any reference to it.
>>>
>>> Thanks,
>>> David
>>>
>>>       The JMM is fine. And
>>>>       store
>>>>       MemBarVolatile
>>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>>> do what is required.
>>>>
>>>> So if you are off soon, please let's come to a solution that
>>>> might be improvable in the way it's implemented, but that
>>>> allows us to implement a correct PPC64 port.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>> Hi everybody,
>>>>>
>>>>> thanks a lot for the detailed reviews!
>>>>> I'll try to answer to all in one mail.
>>>>>
>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>>> We don't think it's correct if we omit the barrier after initializing
>>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>>> and Doug Lea, and they agreed.
>>>>> Also, concurrency torture tests
>>>>>         LongVolatileTest
>>>>>         AtomicIntegerInitialValueTest
>>>>> will fail.
>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>>
>>>> The affects of unsafe publication are always surprising - volatiles do
>>>> not add anything special here. AFAIK there is nothing in the JMM that
>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>> missing constructor barrier.
>>>>
>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>>> see a way to implement this cheaper.
>>>>>
>>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>>> Basically, I agree on this.  But you also have to take into account
>>>>> that due to the different memory ordering instructions on different platforms
>>>>> just implementing something empty is not sufficient.
>>>>> An example:
>>>>>        MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>        MemBarVolatile    // means  StoreLoad barrier
>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>        MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>>        MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>> Just doing what is required.
>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>> fine grained operations:
>>>>>         MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>>        MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>>> MemBarRelease empty, as it is also used independently.
>>>>>
>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>
>>>>> I would propose to guard the code by
>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>> Else, David, how would you propose to implement this platform independent?
>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>
>>>> I can not possibly answer to the necessary level of detail with a few
>>>> moments thought. You are implying there is a problem here that will
>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>> different?) and I can not take that on face value at the moment. The
>>>> only reason I can see IRIW not being handled by the JMM requirements for
>>>> volatile accesses is if there are global visibility issues that are not
>>>> addressed - but even then I would expect heavy barriers at the store
>>>> would deal with that, not at the load. (This situation reminds me of the
>>>> need for read-barriers on Alpha architecture due to the use of software
>>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>>> that on ppc!)
>>>>
>>>> Sorry - There is no quick resolution here and in a couple of days I will
>>>> be heading out on vacation for two weeks.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>> -- Other ports:
>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>
>>>>> -- MemBarStoreStore after initialization
>>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>>> prepare an extra webrev for hotspot-comp.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>> To: Vladimir Kozlov
>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>>
>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>> I have to ask David to do correctness evaluation.
>>>>>
>>>>>       From what I understand what we see here is an attempt to fix an
>>>>> existing issue with the implementation of volatiles so that the IRIW
>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>>> load.
>>>>>
>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>> happy to let them do whatever they like (surely this kills performance
>>>>> though!). But I do not agree with the changes to the shared code that
>>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>>> polluting the shared code. My concern is similar to what I said with the
>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>> given architecture then the implementation in OrderAccess should reduce
>>>>> to a no-op.
>>>>>
>>>>> And as Vitaly points out the constructor barriers are not needed under
>>>>> the JMM.
>>>>>
>>>>>> I am fine with suggested changes because you did not change our current
>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>> But may be it should be done using more general query which is set
>>>>>> depending on platform:
>>>>>>
>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>
>>>>>> or similar to what we use now:
>>>>>>
>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>
>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>> Memory Model, there should not be any need to call this out explicitly
>>>>> like this.
>>>>>
>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>>       From what I understand our ppc port is also affected. David?
>>>>>
>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>>
>>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>
>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>
>>>>>>          if (is_vol) {
>>>>>>            // See comment in do_get_xxx().
>>>>>> #ifndef PPC64
>>>>>>            insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>> #else
>>>>>>            if (is_field) {
>>>>>>              // Add MemBarRelease for constructors which write volatile field
>>>>>> (PPC64).
>>>>>>              set_wrote_volatile(true);
>>>>>>            }
>>>>>> #endif
>>>>>>          }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>>> the torture test suite:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>
>>>>>>> Example:
>>>>>>> volatile x=0, y=0
>>>>>>>         __________    __________    __________    __________
>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>
>>>>>>>          write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>                        read(y)                     read(x)
>>>>>>>
>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>
>>>>>>>
>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>
>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>
>>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>>> written in constructors are visible before the reference gets
>>>>>>> published.
>>>>>>>
>>>>>>>
>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>>> strong.
>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Please review and test this change.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>         Goetz.
>>>>>>>

From david.holmes at oracle.com  Wed Jan 15 19:32:24 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jan 2014 13:32:24 +1000
Subject: RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes
	in C-code.
In-Reply-To: <52B39E70.5020500@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6DA2E@DEWDFEMB12A.global.corp.sap>
	<52B2CFD3.3090303@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE71DA3@DEWDFEMB12A.global.corp.sap>
	<52B39E70.5020500@oracle.com>
Message-ID: <52D752C8.6020502@oracle.com>

I had overlooked the fact that these changes had been pushed and was 
awaiting further discussion. :(

I am concerned about the thread state related changes as they are 
potentially/likely redundant. Thread state transitions generally involve 
full memory fences as part of the transition. Concerns about store 
ordering in the lead up to that, eg _last_java_frame, need to be 
examined in detail to see where the variable is actually read. In many 
cases you will find that variables are only read in conditions where 
there has already been explicit synchronization between the threads 
involved - eg at a safepoint, or when a thread has been suspended etc.

Plus I ask again:
 > With regards to this part of the code do you force UseMembar true for
 > PPC64? The memory serialization page mechanism is not reliable for
 > non-TSO systems.

Cheers,
David
-----

On 20/12/2013 11:33 AM, David Holmes wrote:
> Hi Goetz,
>
> On 20/12/2013 12:19 AM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> the GC stuff is only called from shared code.
>
> Good to hear. I always wonder though whether the cost of passing the
> extra parameter through and checking it, outweighs the benefit of not
> issuing the action (the release in this case)? I'm not a compiler person
> but perhaps the extra parameter forces parameter passing via the stack
> rather than registers, or changes an inlining decision, or maybe the
> additional control flow check causes a problem ... Any hard data that
> not using release semantics all the time actually yields a benefit?
>
>> The ordering in BiasedLocking is needed, e.g., in the context of
>> force_revoke_and_rebias.
>> If an other thread wants to inflate the lock written to the mark word
>> in force_revoke_and_rebias, it must be assured that changing the
>> displaced
>> header is visible to that other thread.
>
> I'll take your word for it. I don't have time to try and analyse the
> BiasedLocking code in depth and I don't think it is a performance issue
> for that code given the potentially redundant barrier occurs during a
> safepoint anyway.
>
>> We added the memory barriers for the _thread_state field in 2006 and can
>> not reconstruct the concrete cause.  But things as setting the
>> last_java_frame
>> and then the state to in_native should be ordered.
>
> I am much more concerned about this. I can't accept a simple wrapping of
> all accesses with acquire/release semantics because there may be a few
> cases where it is needed - this code is too hot for that. We need to
> examine the individual cases, like last_java_frame, where you think
> there is an issue.
>
> With regards to this part of the code do you force UseMembar true for
> PPC64? The memory serialization page mechanism is not reliable for
> non-TSO systems.
>
> My Xmas break begins in about 5 hours but I will be checking in on email
> at times :)
>
> Cheers,
> David
>
>> Best regards,
>>    Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 19. Dezember 2013 11:52
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net';
>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov
>> Subject: Re: RFR (M): 8029396: PPC64 (part 212): Several memory
>> ordering fixes in C-code.
>>
>> Somewhat late but I was away for two weeks.
>>
>> GC stuff:
>>
>> Is the use of the new release parameter always set to true from shared
>> code? If so I don't have a problem with it being used to optimize the
>> stores under certain conditions. But if pcc64 will pass true where other
>> archs won't then again I object to this because it should be an
>> algorithmic correctness requirement that is always present.
>>
>>
>> General: I find a lot of the commentary excessively platform specific.
>> Eg We don't expect any C++ compiler we currently use to emit memory
>> barriers for C++ volatiles. If they start doing that we will have a
>> bazillion unnecessary injected barriers in our code!
>>
>> BiasedLocking:
>>
>> It is not clear to me that the BiasedLocking change is needed. AFAICS
>> there is only one path where revoke_bias is not called at a safepoint
>> and the comments around that seem to indicate that it was considered
>> safe to do so. It may be they assumed TSO when making that decision but
>> I'd be interested to know how this change was arrived at.
>>
>> Thread state:
>>
>> The thread state changes have me most concerned as they are heavily used
>> and so the performance impact here could be extensive. Many of them
>> occur on paths that involve membars or membar-equivalent actions so they
>> would seem redundant then. Again I would like to see some analysis
>> showing these are in fact essential for correctness. There may well be
>> some situations where they are, but to me this seems an even better
>> candidate for adding the "release" parameter when needed!
>>
>> David
>> -----
>>
>> On 3/12/2013 2:51 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> This change contains a row of fixes to the memory ordering in
>>> runtime, GC etc.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029396-0-memo/
>>>
>>> These are:
>>> - Accessing arrays in CMS (compactibleFreeListSpace.cpp)
>>> - CMS: Do release when marking a card dirty. The release must only be
>>> done if GC is running. (several files)
>>> - Method counter initialization (method.hpp).
>>> - Order accessing f1/f2 in constant pool cache.
>>> - Release stores in OopMapCache constructor (instanceKLass.cpp).
>>> - BiasedLocking: Release setting object header to displaced mark.
>>> - Release state of nmethod sweeper (sweeper.cpp).
>>> - Do barriers when writing the thread state (thread.hpp).
>>>
>>> Please review and test this change.
>>>
>>> If requested, I can part this into smaller changes.  But for now
>>> I wanted to put them all into one change as they all address the
>>> problems with the PPC memory model.
>>>
>>> Best regards,
>>>     Goetz.
>>>

From david.holmes at oracle.com  Wed Jan 15 21:25:36 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jan 2014 15:25:36 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
Message-ID: <52D76D50.60700@oracle.com>

On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
> I updated the webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>
> - I removed the IRIW example in parse3.cpp
> - I adapted the comments not to point to that comment, and to
>    reflect the new flagging.  Also I mention that we support the
>    volatile constructor issue, but that it's not standard.
> - I protected issuing the barrier for the constructor by PPC64.
>    I also think it's better to separate these this way.

Sorry if I wasn't clear but I'd like the wrote_volatile field 
declaration and all uses to be guarded by ifdef PPC64 too please.

One nit I missed before. In src/share/vm/opto/library_call.cpp this 
comment doesn't make much sense to me and refers to ppc specific stuff 
in a shared file:

     if (is_volatile) {
!     if (!is_store) {
         insert_mem_bar(Op_MemBarAcquire);
!     } else {
! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
!       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
         insert_mem_bar(Op_MemBarVolatile);
+ #endif
+     }

I don't think the comment is needed.

Thanks,
David

> Thanks for your comments!
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Mittwoch, 15. Januar 2014 01:55
> To: Lindenmaier, Goetz
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi Goetz,
>
> Sorry for the delay in getting back to this.
>
> The general changes to the volatile barriers to support IRIW are okay.
> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
> specifically it is
> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
> the commentary excessive, particularly for shared code. In particular
> the IRIW example in parse3.cpp - it seems a strange place to give the
> explanation and I don't think we need it to that level of detail. Seems
> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>
> The changes related to volatile writes in the constructor, as discussed
> are not required by the Java Memory Model. If you want to keep these
> then I think they should all be guarded with PPC64 because it is not
> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
> PPC64 porters.
>
> Thanks,
> David
>
> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I updated this webrev.  I detected a small flaw I made when editing this version.
>> The #endif in line 322, parse3.cpp was in the wrong line.
>> I also based the webrev on the latest version of the stage repo.
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>
>> Best regards,
>>     Goetz.
>>
>> -----Original Message-----
>> From: Lindenmaier, Goetz
>> Sent: Freitag, 20. Dezember 2013 13:47
>> To: David Holmes
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi David,
>>
>>> So we can at least undo #4 now we have established those tests were not
>>> required to pass.
>> We would prefer if we could keep this in.  We want to avoid that it's
>> blamed on the VM if java programs are failing on PPC after they worked
>> on x86.  To clearly mark it as overfulfilling the spec I would guard it by
>> a flag as proposed.  But if you insist I will remove it.  Also, this part is
>> not that performance relevant.
>>
>>> A compile-time guard (ifdef) would be better than a runtime one I think
>> I added a compile-time guard in this new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>> several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC)
>> but this way I only have to change the ppc platform.
>>
>> Best regards,
>>     Goetz
>>
>> P.S.:  I will also be available over the Christmas period.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 20. Dezember 2013 05:58
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Sorry for the delay, it takes a while to catch up after two weeks
>> vacation :) Next vacation (ie next two weeks) I'll continue to check emails.
>>
>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> ok, I understand the tests are wrong.  It's good this issue is settled.
>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>
>>> About our change:  David, the causality is the other way round.
>>> The change is about IRIW.
>>> 1. To pass IRIW, we must use sync instructions before loads.
>>
>> This is the part I still have some question marks over as the
>> implications are not nice for performance on non-TSO platforms. But I'm
>> no further along in processing that paper I'm afraid.
>>
>>> 2. If we do syncs before loads, we don't need to do them after stores.
>>> 3. If we don't do them after stores, we fail the volatile constructor tests.
>>> 4. So finally we added them again at the end of the constructor after stores
>>>         to pass the volatile constructor tests.
>>
>> So we can at least undo #4 now we have established those tests were not
>> required to pass.
>>
>>> We originally passed the constructor tests because the ppc memory order
>>> instructions are not as find-granular as the
>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
>>> MemBarVolatile after the store fixes the constructor tests.  The proper representation
>>> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
>>> anyways.
>>>
>>>> I'm not happy with the ifdef approach but I won't block it.
>>> I'd be happy to add a property
>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>
>> A compile-time guard (ifdef) would be better than a runtime one I think
>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>> based not architecture based) as that will allows for turning this
>> on/off for any architecture for testing purposes.
>>
>> Thanks,
>> David
>>
>>> or the like to guard the customization.  I'd like that much better. Or also
>>>       OrderAccess::needs_support_iriw_ordering()
>>>       VM_Version::needs_support_iriw_ordering()
>>>
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Donnerstag, 28. November 2013 00:34
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> TL;DR version:
>>>
>>> Discussion on the c-i list has now confirmed that a constructor-barrier
>>> for volatiles is not required as part of the JMM specification. It *may*
>>> be required in an implementation that doesn't pre-zero memory to ensure
>>> you can't see uninitialized fields. So the tests for this are invalid
>>> and this part of the patch is not needed in general (ppc64 may need it
>>> due to other factors).
>>>
>>> Re: "multiple copy atomicity" - first thanks for correcting the term :)
>>> Second thanks for the reference to that paper! For reference:
>>>
>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>> complex interconnect) does not guarantee that a write becomes visible to
>>> all other hardware threads at the same time point; these architectures
>>> are not multiple-copy atomic."
>>>
>>> This is the visibility issue that I referred to and affects both ARM and
>>> PPC. But of course it is normally handled by using suitable barriers
>>> after the stores that need to be visible. I think the crux of the
>>> current issue is what you wrote below:
>>>
>>>     > The fixes for the constructor issue are only needed because we
>>>     > remove the sync instruction from behind stores (parse3.cpp:320)
>>>     > and place it before loads.
>>>
>>> I hadn't grasped this part. Obviously if you fail to do the sync after
>>> the store then you have to do something around the loads to get the same
>>> results! I still don't know what lead you to the conclusion that the
>>> only way to fix the IRIW issue was to put the fence before the load -
>>> maybe when I get the chance to read that paper in full it will be clearer.
>>>
>>> So ... the basic problem is that the current structure in the VM has
>>> hard-wired one choice of how to get the right semantics for volatile
>>> variables. You now want to customize that but not all the requisite
>>> hooks are present. It would be better if volatile_load and
>>> volatile_store were factored out so that they could be implemented as
>>> desired per-platform. Alternatively there could be pre- and post- hooks
>>> that could then be customized per platform. Otherwise you need
>>> platform-specific ifdef's to handle it as per your patch.
>>>
>>> I'm not happy with the ifdef approach but I won't block it. I think this
>>> is an area where a lot of clean up is needed in the VM. The barrier
>>> abstractions are a confused mess in my opinion.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>
>>>> I did not yet add the
>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>        VM_Version::needs_support_iriw_ordering()
>>>> or
>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>> to reduce #defined, as I got no further comment on that.
>>>>
>>>>
>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>> I feel not in the position to contribute substantially.
>>>>
>>>> But we would like to pass the torture test suite as we consider
>>>> this a substantial task in implementing a PPC port.  Also we think
>>>> both tests show behavior a programmer would expect.  It's bad if
>>>> Java code runs fine on the more common x86 platform, and then
>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>
>>>> The fixes for the constructor issue are only needed because we
>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>> and place it before loads.  Then there is no sync between volatile store
>>>> and publishing the object.  So we add it again in this one case
>>>> (volatile store in constructor).
>>>>
>>>>
>>>> @David
>>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>>> and that's being discussed now for almost a year.
>>>>> It may have started a year ago but work on it has hardly been continuous.
>>>> That's not true, we did a lot of investigation and testing on this issue.
>>>> And we came up with a solution we consider the best possible. If you
>>>> have objections, you should at least give the draft of a better solution,
>>>> we would volunteer to implement and test it.
>>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>>
>>>> @David
>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>>> can't find any reference to it.
>>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>
>>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>>>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>>>
>>>> Best regards and thanks for all your involvements,
>>>>       Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>> Hi David,
>>>>>
>>>>> -- Volatile in constuctor
>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>> missing constructor barrier.
>>>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>>
>>>> And see follow ups - the tests are invalid.
>>>>
>>>>> -- IRIW issue
>>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>>> moments thought.
>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>> and that's being discussed now for almost a year.
>>>>
>>>> It may have started a year ago but work on it has hardly been continuous.
>>>>
>>>>>> You are implying there is a problem here that will
>>>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>>>> (I don't really know about ARM, though).
>>>>> So if I can write down a nicer solution testing for methods that are evaluated
>>>>> by the C-compiler I'm happy.
>>>>>
>>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>>> is that
>>>>>        store
>>>>>        sync
>>>>> does not assure multiple-read-atomicity,
>>>>> only
>>>>>        sync
>>>>>        load
>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>> pass that test.
>>>>
>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>> can't find any reference to it.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>        The JMM is fine. And
>>>>>        store
>>>>>        MemBarVolatile
>>>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>>>> do what is required.
>>>>>
>>>>> So if you are off soon, please let's come to a solution that
>>>>> might be improvable in the way it's implemented, but that
>>>>> allows us to implement a correct PPC64 port.
>>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi everybody,
>>>>>>
>>>>>> thanks a lot for the detailed reviews!
>>>>>> I'll try to answer to all in one mail.
>>>>>>
>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>>>> We don't think it's correct if we omit the barrier after initializing
>>>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>>>> and Doug Lea, and they agreed.
>>>>>> Also, concurrency torture tests
>>>>>>          LongVolatileTest
>>>>>>          AtomicIntegerInitialValueTest
>>>>>> will fail.
>>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>>>
>>>>> The affects of unsafe publication are always surprising - volatiles do
>>>>> not add anything special here. AFAIK there is nothing in the JMM that
>>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>> missing constructor barrier.
>>>>>
>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>>>> see a way to implement this cheaper.
>>>>>>
>>>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>>>> Basically, I agree on this.  But you also have to take into account
>>>>>> that due to the different memory ordering instructions on different platforms
>>>>>> just implementing something empty is not sufficient.
>>>>>> An example:
>>>>>>         MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>         MemBarVolatile    // means  StoreLoad barrier
>>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>>         MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>>>         MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>> Just doing what is required.
>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>> fine grained operations:
>>>>>>          MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>>>         MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>
>>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>
>>>>>> I would propose to guard the code by
>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>> Else, David, how would you propose to implement this platform independent?
>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>
>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>> moments thought. You are implying there is a problem here that will
>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>> different?) and I can not take that on face value at the moment. The
>>>>> only reason I can see IRIW not being handled by the JMM requirements for
>>>>> volatile accesses is if there are global visibility issues that are not
>>>>> addressed - but even then I would expect heavy barriers at the store
>>>>> would deal with that, not at the load. (This situation reminds me of the
>>>>> need for read-barriers on Alpha architecture due to the use of software
>>>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>>>> that on ppc!)
>>>>>
>>>>> Sorry - There is no quick resolution here and in a couple of days I will
>>>>> be heading out on vacation for two weeks.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Best regards,
>>>>>>         Goetz.
>>>>>>
>>>>>> -- Other ports:
>>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>>
>>>>>> -- MemBarStoreStore after initialization
>>>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>> To: Vladimir Kozlov
>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>>
>>>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>>>
>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>
>>>>>>        From what I understand what we see here is an attempt to fix an
>>>>>> existing issue with the implementation of volatiles so that the IRIW
>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>>>> load.
>>>>>>
>>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>>> happy to let them do whatever they like (surely this kills performance
>>>>>> though!). But I do not agree with the changes to the shared code that
>>>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>>>> polluting the shared code. My concern is similar to what I said with the
>>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>>> given architecture then the implementation in OrderAccess should reduce
>>>>>> to a no-op.
>>>>>>
>>>>>> And as Vitaly points out the constructor barriers are not needed under
>>>>>> the JMM.
>>>>>>
>>>>>>> I am fine with suggested changes because you did not change our current
>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>> But may be it should be done using more general query which is set
>>>>>>> depending on platform:
>>>>>>>
>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>
>>>>>>> or similar to what we use now:
>>>>>>>
>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>
>>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>>> Memory Model, there should not be any need to call this out explicitly
>>>>>> like this.
>>>>>>
>>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>>>        From what I understand our ppc port is also affected. David?
>>>>>>
>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>>>
>>>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>>
>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>
>>>>>>>           if (is_vol) {
>>>>>>>             // See comment in do_get_xxx().
>>>>>>> #ifndef PPC64
>>>>>>>             insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>> #else
>>>>>>>             if (is_field) {
>>>>>>>               // Add MemBarRelease for constructors which write volatile field
>>>>>>> (PPC64).
>>>>>>>               set_wrote_volatile(true);
>>>>>>>             }
>>>>>>> #endif
>>>>>>>           }
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>>>> the torture test suite:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>
>>>>>>>> Example:
>>>>>>>> volatile x=0, y=0
>>>>>>>>          __________    __________    __________    __________
>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>
>>>>>>>>           write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>                         read(y)                     read(x)
>>>>>>>>
>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>
>>>>>>>>
>>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>
>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>
>>>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>> published.
>>>>>>>>
>>>>>>>>
>>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>>>> strong.
>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Please review and test this change.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>          Goetz.
>>>>>>>>

From david.holmes at oracle.com  Wed Jan 15 21:30:23 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jan 2014 15:30:23 +1000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <52B3A3AF.9050609@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>
	<52B3A3AF.9050609@oracle.com>
Message-ID: <52D76E6F.8070504@oracle.com>

Can I get some response on this please - specifically the redundancy wrt 
IRT_ENTRY actions.

Thanks,
David

On 20/12/2013 11:55 AM, David Holmes wrote:
> Still catching up ...
>
> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> this change adds StoreStore barriers after object initialization and
>> after constructor calls in the C++ interpreter.  This assures no
>> uninitialized
>> objects or final fields are visible.
>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>
> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
> thread state transitions that already include a full "fence" so the
> storestore barriers are redundant in those cases.
>
> The fastpath _new storestore seems okay.
>
> I don't know how handle_return gets used to know if it is reasonable or
> not.
>
> I was trying, unsuccessfully, to examine the same code in the
> templateInterpreter to see how it handles these cases as it naturally
> has the same object-initialization-safety requirements (though these can
> be handled in a number of different ways other than an unconditional
> storestore barrier at the end of the initialization and construction
> phases.
>
> David
> -----
>
>> Please review and test this change.
>>
>> Best regards,
>>    Goetz.
>>

From vladimir.kozlov at oracle.com  Wed Jan 15 23:13:27 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 15 Jan 2014 23:13:27 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52D76D50.60700@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5293F087.2080700@oracle.com>
	<5293FE15.9050100@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com>
Message-ID: <52D78697.2090408@oracle.com>

This is becoming ugly #ifdef mess. In compiler code we are trying to avoid them. I suggested to have _wrote_volatile 
without #ifdef and I want to keep it this way, it could be useful to have such info on other platforms too. But I would 
suggest to remove PPC64 comments in parse.hpp.

In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value which could be checked in all places instead of 
#ifdef:

#ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
#else
const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
#endif

or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever

and then:

  #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
    oop p = JNIHandles::resolve(obj); \
+  if (support_IRIW_for_not_multiple_copy_atomic_cpu) OrderAccess::fence(); \
    volatile type_name v = OrderAccess::load_acquire((volatile type_name*)index_oop_from_field_offset_long(p, offset));

And:

+  if (support_IRIW_for_not_multiple_copy_atomic_cpu && field->is_volatile()) {
+    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
+  }

And so on. The comments will be needed only in globalDefinitions.hpp

The code in parse1.cpp could be put on one line:

+  if (wrote_final() PPC64_ONLY( || (wrote_volatile() && method()->is_initializer()) )) {

Thanks,
Vladimir

On 1/15/14 9:25 PM, David Holmes wrote:
> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> I updated the webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>
>> - I removed the IRIW example in parse3.cpp
>> - I adapted the comments not to point to that comment, and to
>>    reflect the new flagging.  Also I mention that we support the
>>    volatile constructor issue, but that it's not standard.
>> - I protected issuing the barrier for the constructor by PPC64.
>>    I also think it's better to separate these this way.
>
> Sorry if I wasn't clear but I'd like the wrote_volatile field declaration and all uses to be guarded by ifdef PPC64 too
> please.
>
> One nit I missed before. In src/share/vm/opto/library_call.cpp this comment doesn't make much sense to me and refers to
> ppc specific stuff in a shared file:
>
>      if (is_volatile) {
> !     if (!is_store) {
>          insert_mem_bar(Op_MemBarAcquire);
> !     } else {
> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>          insert_mem_bar(Op_MemBarVolatile);
> + #endif
> +     }
>
> I don't think the comment is needed.
>
> Thanks,
> David
>
>> Thanks for your comments!
>>
>> Best regards,
>>    Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Mittwoch, 15. Januar 2014 01:55
>> To: Lindenmaier, Goetz
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz,
>>
>> Sorry for the delay in getting back to this.
>>
>> The general changes to the volatile barriers to support IRIW are okay.
>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>> specifically it is
>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>> the commentary excessive, particularly for shared code. In particular
>> the IRIW example in parse3.cpp - it seems a strange place to give the
>> explanation and I don't think we need it to that level of detail. Seems
>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>
>> The changes related to volatile writes in the constructor, as discussed
>> are not required by the Java Memory Model. If you want to keep these
>> then I think they should all be guarded with PPC64 because it is not
>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>> PPC64 porters.
>>
>> Thanks,
>> David
>>
>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I updated this webrev.  I detected a small flaw I made when editing this version.
>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>> I also based the webrev on the latest version of the stage repo.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>> -----Original Message-----
>>> From: Lindenmaier, Goetz
>>> Sent: Freitag, 20. Dezember 2013 13:47
>>> To: David Holmes
>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi David,
>>>
>>>> So we can at least undo #4 now we have established those tests were not
>>>> required to pass.
>>> We would prefer if we could keep this in.  We want to avoid that it's
>>> blamed on the VM if java programs are failing on PPC after they worked
>>> on x86.  To clearly mark it as overfulfilling the spec I would guard it by
>>> a flag as proposed.  But if you insist I will remove it.  Also, this part is
>>> not that performance relevant.
>>>
>>>> A compile-time guard (ifdef) would be better than a runtime one I think
>>> I added a compile-time guard in this new webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>> several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>> but this way I only have to change the ppc platform.
>>>
>>> Best regards,
>>>     Goetz
>>>
>>> P.S.:  I will also be available over the Christmas period.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Freitag, 20. Dezember 2013 05:58
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Sorry for the delay, it takes a while to catch up after two weeks
>>> vacation :) Next vacation (ie next two weeks) I'll continue to check emails.
>>>
>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> ok, I understand the tests are wrong.  It's good this issue is settled.
>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>
>>>> About our change:  David, the causality is the other way round.
>>>> The change is about IRIW.
>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>
>>> This is the part I still have some question marks over as the
>>> implications are not nice for performance on non-TSO platforms. But I'm
>>> no further along in processing that paper I'm afraid.
>>>
>>>> 2. If we do syncs before loads, we don't need to do them after stores.
>>>> 3. If we don't do them after stores, we fail the volatile constructor tests.
>>>> 4. So finally we added them again at the end of the constructor after stores
>>>>         to pass the volatile constructor tests.
>>>
>>> So we can at least undo #4 now we have established those tests were not
>>> required to pass.
>>>
>>>> We originally passed the constructor tests because the ppc memory order
>>>> instructions are not as find-granular as the
>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.  The only instruction
>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the
>>>> MemBarVolatile after the store fixes the constructor tests.  The proper representation
>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now it's pointless
>>>> anyways.
>>>>
>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>> I'd be happy to add a property
>>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>>
>>> A compile-time guard (ifdef) would be better than a runtime one I think
>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>> based not architecture based) as that will allows for turning this
>>> on/off for any architecture for testing purposes.
>>>
>>> Thanks,
>>> David
>>>
>>>> or the like to guard the customization.  I'd like that much better. Or also
>>>>       OrderAccess::needs_support_iriw_ordering()
>>>>       VM_Version::needs_support_iriw_ordering()
>>>>
>>>>
>>>> Best regards,
>>>>      Goetz.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> TL;DR version:
>>>>
>>>> Discussion on the c-i list has now confirmed that a constructor-barrier
>>>> for volatiles is not required as part of the JMM specification. It *may*
>>>> be required in an implementation that doesn't pre-zero memory to ensure
>>>> you can't see uninitialized fields. So the tests for this are invalid
>>>> and this part of the patch is not needed in general (ppc64 may need it
>>>> due to other factors).
>>>>
>>>> Re: "multiple copy atomicity" - first thanks for correcting the term :)
>>>> Second thanks for the reference to that paper! For reference:
>>>>
>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>> complex interconnect) does not guarantee that a write becomes visible to
>>>> all other hardware threads at the same time point; these architectures
>>>> are not multiple-copy atomic."
>>>>
>>>> This is the visibility issue that I referred to and affects both ARM and
>>>> PPC. But of course it is normally handled by using suitable barriers
>>>> after the stores that need to be visible. I think the crux of the
>>>> current issue is what you wrote below:
>>>>
>>>>     > The fixes for the constructor issue are only needed because we
>>>>     > remove the sync instruction from behind stores (parse3.cpp:320)
>>>>     > and place it before loads.
>>>>
>>>> I hadn't grasped this part. Obviously if you fail to do the sync after
>>>> the store then you have to do something around the loads to get the same
>>>> results! I still don't know what lead you to the conclusion that the
>>>> only way to fix the IRIW issue was to put the fence before the load -
>>>> maybe when I get the chance to read that paper in full it will be clearer.
>>>>
>>>> So ... the basic problem is that the current structure in the VM has
>>>> hard-wired one choice of how to get the right semantics for volatile
>>>> variables. You now want to customize that but not all the requisite
>>>> hooks are present. It would be better if volatile_load and
>>>> volatile_store were factored out so that they could be implemented as
>>>> desired per-platform. Alternatively there could be pre- and post- hooks
>>>> that could then be customized per platform. Otherwise you need
>>>> platform-specific ifdef's to handle it as per your patch.
>>>>
>>>> I'm not happy with the ifdef approach but I won't block it. I think this
>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>> abstractions are a confused mess in my opinion.
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>
>>>>> I did not yet add the
>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>> or
>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>> to reduce #defined, as I got no further comment on that.
>>>>>
>>>>>
>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>> I feel not in the position to contribute substantially.
>>>>>
>>>>> But we would like to pass the torture test suite as we consider
>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>> Java code runs fine on the more common x86 platform, and then
>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>
>>>>> The fixes for the constructor issue are only needed because we
>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>> and place it before loads.  Then there is no sync between volatile store
>>>>> and publishing the object.  So we add it again in this one case
>>>>> (volatile store in constructor).
>>>>>
>>>>>
>>>>> @David
>>>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>>>> and that's being discussed now for almost a year.
>>>>>> It may have started a year ago but work on it has hardly been continuous.
>>>>> That's not true, we did a lot of investigation and testing on this issue.
>>>>> And we came up with a solution we consider the best possible. If you
>>>>> have objections, you should at least give the draft of a better solution,
>>>>> we would volunteer to implement and test it.
>>>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>>>
>>>>> @David
>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>>>> can't find any reference to it.
>>>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for
>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem.
>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>
>>>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read'
>>>>> instead.  Sorry for that.  (I also fixed that in the method name above).
>>>>>
>>>>> Best regards and thanks for all your involvements,
>>>>>       Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> -- Volatile in constuctor
>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>> missing constructor barrier.
>>>>>> We see them on PPC64. Our test machines have typically 8-32 processors
>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>>>
>>>>> And see follow ups - the tests are invalid.
>>>>>
>>>>>> -- IRIW issue
>>>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>>>> moments thought.
>>>>>> Sure.  There also is no solution as you require for the taskqueue problem yet,
>>>>>> and that's being discussed now for almost a year.
>>>>>
>>>>> It may have started a year ago but work on it has hardly been continuous.
>>>>>
>>>>>>> You are implying there is a problem here that will
>>>>>>> impact numerous platforms (unless you can tell me why ppc is so different?)
>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore I contributed a
>>>>>> solution with the #defines, and that's correct for all, but not nice, I admit.
>>>>>> (I don't really know about ARM, though).
>>>>>> So if I can write down a nicer solution testing for methods that are evaluated
>>>>>> by the C-compiler I'm happy.
>>>>>>
>>>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>>>> is that
>>>>>>        store
>>>>>>        sync
>>>>>> does not assure multiple-read-atomicity,
>>>>>> only
>>>>>>        sync
>>>>>>        load
>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>> pass that test.
>>>>>
>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>>> can't find any reference to it.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>        The JMM is fine. And
>>>>>>        store
>>>>>>        MemBarVolatile
>>>>>> is fine on x86, sparc etc. as there exist assembler instructions that
>>>>>> do what is required.
>>>>>>
>>>>>> So if you are off soon, please let's come to a solution that
>>>>>> might be improvable in the way it's implemented, but that
>>>>>> allows us to implement a correct PPC64 port.
>>>>>>
>>>>>> Best regards,
>>>>>>        Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi everybody,
>>>>>>>
>>>>>>> thanks a lot for the detailed reviews!
>>>>>>> I'll try to answer to all in one mail.
>>>>>>>
>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned;
>>>>>>> We don't think it's correct if we omit the barrier after initializing
>>>>>>> a volatile field.  Previously, we discussed this with Aleksey Shipilev
>>>>>>> and Doug Lea, and they agreed.
>>>>>>> Also, concurrency torture tests
>>>>>>>          LongVolatileTest
>>>>>>>          AtomicIntegerInitialValueTest
>>>>>>> will fail.
>>>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be
>>>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.)
>>>>>>
>>>>>> The affects of unsafe publication are always surprising - volatiles do
>>>>>> not add anything special here. AFAIK there is nothing in the JMM that
>>>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>> missing constructor barrier.
>>>>>>
>>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We don't
>>>>>>> see a way to implement this cheaper.
>>>>>>>
>>>>>>>> - these algorithms should be expressed using the correct OrderAccess operations
>>>>>>> Basically, I agree on this.  But you also have to take into account
>>>>>>> that due to the different memory ordering instructions on different platforms
>>>>>>> just implementing something empty is not sufficient.
>>>>>>> An example:
>>>>>>>         MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>         MemBarVolatile    // means  StoreLoad barrier
>>>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>>>         MemBarRelease  --> membar(Assembler::LoadStore | Assembler::StoreStore)
>>>>>>>         MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>> Just doing what is required.
>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>> fine grained operations:
>>>>>>>          MemBarRelease --> lwsync   // Doing LoadStore, StoreStore, LoadLoad
>>>>>>>         MemBarVolatile --> sync    // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad
>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations are more (too) powerful,
>>>>>>> I need an additional optimization that removes the lwsync.  I can not implement
>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>
>>>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read
>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>
>>>>>>> I would propose to guard the code by
>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>> Else, David, how would you propose to implement this platform independent?
>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>
>>>>>> I can not possibly answer to the necessary level of detail with a few
>>>>>> moments thought. You are implying there is a problem here that will
>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>> different?) and I can not take that on face value at the moment. The
>>>>>> only reason I can see IRIW not being handled by the JMM requirements for
>>>>>> volatile accesses is if there are global visibility issues that are not
>>>>>> addressed - but even then I would expect heavy barriers at the store
>>>>>> would deal with that, not at the load. (This situation reminds me of the
>>>>>> need for read-barriers on Alpha architecture due to the use of software
>>>>>> cache-coherency rather than hardware cache-coherency - but we don't have
>>>>>> that on ppc!)
>>>>>>
>>>>>> Sorry - There is no quick resolution here and in a couple of days I will
>>>>>> be heading out on vacation for two weeks.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Best regards,
>>>>>>>         Goetz.
>>>>>>>
>>>>>>> -- Other ports:
>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might
>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>>>
>>>>>>> -- MemBarStoreStore after initialization
>>>>>>> I agree we should not change it in the ppc port.  If you wish, I can
>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>> To: Vladimir Kozlov
>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Okay this is my second attempt at answering this in a reasonable way :)
>>>>>>>
>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>
>>>>>>>        From what I understand what we see here is an attempt to fix an
>>>>>>> existing issue with the implementation of volatiles so that the IRIW
>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>> volatile reads extremely heavyweight by adding a fence() when doing the
>>>>>>> load.
>>>>>>>
>>>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>>>> happy to let them do whatever they like (surely this kills performance
>>>>>>> though!). But I do not agree with the changes to the shared code that
>>>>>>> allow this solution to be implemented - even with PPC64_ONLY this is
>>>>>>> polluting the shared code. My concern is similar to what I said with the
>>>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>>>> given architecture then the implementation in OrderAccess should reduce
>>>>>>> to a no-op.
>>>>>>>
>>>>>>> And as Vitaly points out the constructor barriers are not needed under
>>>>>>> the JMM.
>>>>>>>
>>>>>>>> I am fine with suggested changes because you did not change our current
>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>> But may be it should be done using more general query which is set
>>>>>>>> depending on platform:
>>>>>>>>
>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>
>>>>>>>> or similar to what we use now:
>>>>>>>>
>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>
>>>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>>>> Memory Model, there should not be any need to call this out explicitly
>>>>>>> like this.
>>>>>>>
>>>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>>>> visibility issues beyond the ordering constraints that the JMM defines?
>>>>>>>>        From what I understand our ppc port is also affected. David?
>>>>>>>
>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> In library_call.cpp can you add {}? New comment should be inside  else {}.
>>>>>>>>
>>>>>>>> I think you should make _wrote_volatile field not ppc64 specific which
>>>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY()
>>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>>>
>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>
>>>>>>>>           if (is_vol) {
>>>>>>>>             // See comment in do_get_xxx().
>>>>>>>> #ifndef PPC64
>>>>>>>>             insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>> #else
>>>>>>>>             if (is_field) {
>>>>>>>>               // Add MemBarRelease for constructors which write volatile field
>>>>>>>> (PPC64).
>>>>>>>>               set_wrote_volatile(true);
>>>>>>>>             }
>>>>>>>> #endif
>>>>>>>>           }
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of
>>>>>>>>> the torture test suite:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>
>>>>>>>>> Example:
>>>>>>>>> volatile x=0, y=0
>>>>>>>>>          __________    __________    __________    __________
>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>
>>>>>>>>>           write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>                         read(y)                     read(x)
>>>>>>>>>
>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only
>>>>>>>>> assured by the sync instruction and if it is executed in the threads
>>>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire
>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>
>>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>
>>>>>>>>> Further this change contains a fix that assures that volatile fields
>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>> published.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too
>>>>>>>>> strong.
>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Please review and test this change.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>          Goetz.
>>>>>>>>>

From david.holmes at oracle.com  Thu Jan 16 00:34:10 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jan 2014 18:34:10 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52D78697.2090408@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5293F087.2080700@oracle.com>
	<5293FE15.9050100@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
Message-ID: <52D79982.4060100@oracle.com>

On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
> This is becoming ugly #ifdef mess. In compiler code we are trying to
> avoid them. I suggested to have _wrote_volatile without #ifdef and I
> want to keep it this way, it could be useful to have such info on other
> platforms too. But I would suggest to remove PPC64 comments in parse.hpp.
>
> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
> which could be checked in all places instead of #ifdef:

I asked for the ifdef some time back as I find it much preferable to 
have this as a build-time construct rather than a runtime one. I don't 
want to have to pay anything for this if we don't use it.

David

> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
> #else
> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
> #endif
>
> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>
> and then:
>
>   #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>     oop p = JNIHandles::resolve(obj); \
> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
> OrderAccess::fence(); \
>     volatile type_name v = OrderAccess::load_acquire((volatile
> type_name*)index_oop_from_field_offset_long(p, offset));
>
> And:
>
> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
> field->is_volatile()) {
> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
> +  }
>
> And so on. The comments will be needed only in globalDefinitions.hpp
>
> The code in parse1.cpp could be put on one line:
>
> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
> method()->is_initializer()) )) {
>
> Thanks,
> Vladimir
>
> On 1/15/14 9:25 PM, David Holmes wrote:
>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> I updated the webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>
>>> - I removed the IRIW example in parse3.cpp
>>> - I adapted the comments not to point to that comment, and to
>>>    reflect the new flagging.  Also I mention that we support the
>>>    volatile constructor issue, but that it's not standard.
>>> - I protected issuing the barrier for the constructor by PPC64.
>>>    I also think it's better to separate these this way.
>>
>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>> declaration and all uses to be guarded by ifdef PPC64 too
>> please.
>>
>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>> comment doesn't make much sense to me and refers to
>> ppc specific stuff in a shared file:
>>
>>      if (is_volatile) {
>> !     if (!is_store) {
>>          insert_mem_bar(Op_MemBarAcquire);
>> !     } else {
>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>          insert_mem_bar(Op_MemBarVolatile);
>> + #endif
>> +     }
>>
>> I don't think the comment is needed.
>>
>> Thanks,
>> David
>>
>>> Thanks for your comments!
>>>
>>> Best regards,
>>>    Goetz.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>> To: Lindenmaier, Goetz
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>> Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> Sorry for the delay in getting back to this.
>>>
>>> The general changes to the volatile barriers to support IRIW are okay.
>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>> specifically it is
>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>> the commentary excessive, particularly for shared code. In particular
>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>> explanation and I don't think we need it to that level of detail. Seems
>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>
>>> The changes related to volatile writes in the constructor, as discussed
>>> are not required by the Java Memory Model. If you want to keep these
>>> then I think they should all be guarded with PPC64 because it is not
>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>> PPC64 porters.
>>>
>>> Thanks,
>>> David
>>>
>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>> this version.
>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>> I also based the webrev on the latest version of the stage repo.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>
>>>> Best regards,
>>>>     Goetz.
>>>>
>>>> -----Original Message-----
>>>> From: Lindenmaier, Goetz
>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>> To: David Holmes
>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>> Independent Reads of Independent Writes
>>>>
>>>> Hi David,
>>>>
>>>>> So we can at least undo #4 now we have established those tests were
>>>>> not
>>>>> required to pass.
>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>> blamed on the VM if java programs are failing on PPC after they worked
>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>> it by
>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>> part is
>>>> not that performance relevant.
>>>>
>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>> think
>>>> I added a compile-time guard in this new webrev:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>> several double negations I don't like, (#ifNdef
>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>> but this way I only have to change the ppc platform.
>>>>
>>>> Best regards,
>>>>     Goetz
>>>>
>>>> P.S.:  I will also be available over the Christmas period.
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>> Independent Reads of Independent Writes
>>>>
>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>> emails.
>>>>
>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>> settled.
>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>
>>>>> About our change:  David, the causality is the other way round.
>>>>> The change is about IRIW.
>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>
>>>> This is the part I still have some question marks over as the
>>>> implications are not nice for performance on non-TSO platforms. But I'm
>>>> no further along in processing that paper I'm afraid.
>>>>
>>>>> 2. If we do syncs before loads, we don't need to do them after stores.
>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>> constructor tests.
>>>>> 4. So finally we added them again at the end of the constructor
>>>>> after stores
>>>>>         to pass the volatile constructor tests.
>>>>
>>>> So we can at least undo #4 now we have established those tests were not
>>>> required to pass.
>>>>
>>>>> We originally passed the constructor tests because the ppc memory
>>>>> order
>>>>> instructions are not as find-granular as the
>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>> The only instruction
>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>> therefore the
>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>> proper representation
>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>> it's pointless
>>>>> anyways.
>>>>>
>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>> I'd be happy to add a property
>>>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>>>
>>>> A compile-time guard (ifdef) would be better than a runtime one I think
>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>> based not architecture based) as that will allows for turning this
>>>> on/off for any architecture for testing purposes.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> or the like to guard the customization.  I'd like that much better.
>>>>> Or also
>>>>>       OrderAccess::needs_support_iriw_ordering()
>>>>>       VM_Version::needs_support_iriw_ordering()
>>>>>
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>> Independent Reads of Independent Writes
>>>>>
>>>>> TL;DR version:
>>>>>
>>>>> Discussion on the c-i list has now confirmed that a
>>>>> constructor-barrier
>>>>> for volatiles is not required as part of the JMM specification. It
>>>>> *may*
>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>> ensure
>>>>> you can't see uninitialized fields. So the tests for this are invalid
>>>>> and this part of the patch is not needed in general (ppc64 may need it
>>>>> due to other factors).
>>>>>
>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>> term :)
>>>>> Second thanks for the reference to that paper! For reference:
>>>>>
>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>> complex interconnect) does not guarantee that a write becomes
>>>>> visible to
>>>>> all other hardware threads at the same time point; these architectures
>>>>> are not multiple-copy atomic."
>>>>>
>>>>> This is the visibility issue that I referred to and affects both
>>>>> ARM and
>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>> after the stores that need to be visible. I think the crux of the
>>>>> current issue is what you wrote below:
>>>>>
>>>>>     > The fixes for the constructor issue are only needed because we
>>>>>     > remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>     > and place it before loads.
>>>>>
>>>>> I hadn't grasped this part. Obviously if you fail to do the sync after
>>>>> the store then you have to do something around the loads to get the
>>>>> same
>>>>> results! I still don't know what lead you to the conclusion that the
>>>>> only way to fix the IRIW issue was to put the fence before the load -
>>>>> maybe when I get the chance to read that paper in full it will be
>>>>> clearer.
>>>>>
>>>>> So ... the basic problem is that the current structure in the VM has
>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>> variables. You now want to customize that but not all the requisite
>>>>> hooks are present. It would be better if volatile_load and
>>>>> volatile_store were factored out so that they could be implemented as
>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>> hooks
>>>>> that could then be customized per platform. Otherwise you need
>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>
>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>> this
>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>> abstractions are a confused mess in my opinion.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>
>>>>>> I did not yet add the
>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>> or
>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>
>>>>>>
>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>> I feel not in the position to contribute substantially.
>>>>>>
>>>>>> But we would like to pass the torture test suite as we consider
>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>
>>>>>> The fixes for the constructor issue are only needed because we
>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>> store
>>>>>> and publishing the object.  So we add it again in this one case
>>>>>> (volatile store in constructor).
>>>>>>
>>>>>>
>>>>>> @David
>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>> taskqueue problem yet,
>>>>>>>> and that's being discussed now for almost a year.
>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>> continuous.
>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>> issue.
>>>>>> And we came up with a solution we consider the best possible. If you
>>>>>> have objections, you should at least give the draft of a better
>>>>>> solution,
>>>>>> we would volunteer to implement and test it.
>>>>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>>>>
>>>>>> @David
>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>> and
>>>>>>> can't find any reference to it.
>>>>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>> Work-Stealing for
>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>> taskqueue problem.
>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>
>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>> used 'read'
>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>> above).
>>>>>>
>>>>>> Best regards and thanks for all your involvements,
>>>>>>       Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> -- Volatile in constuctor
>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>> missing constructor barrier.
>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>> processors
>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>>>>
>>>>>> And see follow ups - the tests are invalid.
>>>>>>
>>>>>>> -- IRIW issue
>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>> a few
>>>>>>>> moments thought.
>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>> problem yet,
>>>>>>> and that's being discussed now for almost a year.
>>>>>>
>>>>>> It may have started a year ago but work on it has hardly been
>>>>>> continuous.
>>>>>>
>>>>>>>> You are implying there is a problem here that will
>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>> different?)
>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>> I contributed a
>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>> nice, I admit.
>>>>>>> (I don't really know about ARM, though).
>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>> are evaluated
>>>>>>> by the C-compiler I'm happy.
>>>>>>>
>>>>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>>>>> is that
>>>>>>>        store
>>>>>>>        sync
>>>>>>> does not assure multiple-read-atomicity,
>>>>>>> only
>>>>>>>        sync
>>>>>>>        load
>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>> pass that test.
>>>>>>
>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>>>> can't find any reference to it.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>        The JMM is fine. And
>>>>>>>        store
>>>>>>>        MemBarVolatile
>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>> that
>>>>>>> do what is required.
>>>>>>>
>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>        Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>> 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi Goetz,
>>>>>>>
>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi everybody,
>>>>>>>>
>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>
>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>> to occur before the reference is assigned;
>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>> initializing
>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>> Shipilev
>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>> Also, concurrency torture tests
>>>>>>>>          LongVolatileTest
>>>>>>>>          AtomicIntegerInitialValueTest
>>>>>>>> will fail.
>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>> volatile field would be
>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>> AtomicInteger.)
>>>>>>>
>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>> volatiles do
>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>> that
>>>>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>> missing constructor barrier.
>>>>>>>
>>>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>> don't
>>>>>>>> see a way to implement this cheaper.
>>>>>>>>
>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>> OrderAccess operations
>>>>>>>> Basically, I agree on this.  But you also have to take into account
>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>> different platforms
>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>> An example:
>>>>>>>>         MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>         MemBarVolatile    // means  StoreLoad barrier
>>>>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>>>>         MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>> Assembler::StoreStore)
>>>>>>>>         MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>> Just doing what is required.
>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>> fine grained operations:
>>>>>>>>          MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>> StoreStore, LoadLoad
>>>>>>>>         MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>> are more (too) powerful,
>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>> can not implement
>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>
>>>>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>> read
>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>
>>>>>>>> I would propose to guard the code by
>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>> independent?
>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>
>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>> few
>>>>>>> moments thought. You are implying there is a problem here that will
>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>> different?) and I can not take that on face value at the moment. The
>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>> requirements for
>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>> are not
>>>>>>> addressed - but even then I would expect heavy barriers at the store
>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>> of the
>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>> software
>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>> don't have
>>>>>>> that on ppc!)
>>>>>>>
>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>> I will
>>>>>>> be heading out on vacation for two weeks.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>         Goetz.
>>>>>>>>
>>>>>>>> -- Other ports:
>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>> it might
>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>>>>
>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>> can
>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>> To: Vladimir Kozlov
>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>> way :)
>>>>>>>>
>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>
>>>>>>>>        From what I understand what we see here is an attempt to
>>>>>>>> fix an
>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>> IRIW
>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>> doing the
>>>>>>>> load.
>>>>>>>>
>>>>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>> performance
>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>> that
>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>> this is
>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>> with the
>>>>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>> reduce
>>>>>>>> to a no-op.
>>>>>>>>
>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>> under
>>>>>>>> the JMM.
>>>>>>>>
>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>> current
>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>> But may be it should be done using more general query which is set
>>>>>>>>> depending on platform:
>>>>>>>>>
>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>
>>>>>>>>> or similar to what we use now:
>>>>>>>>>
>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>
>>>>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>> explicitly
>>>>>>>> like this.
>>>>>>>>
>>>>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>> defines?
>>>>>>>>>        From what I understand our ppc port is also affected.
>>>>>>>>> David?
>>>>>>>>
>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>> inside  else {}.
>>>>>>>>>
>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>> specific which
>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>> PPC64_ONLY()
>>>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>>>>
>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>
>>>>>>>>>           if (is_vol) {
>>>>>>>>>             // See comment in do_get_xxx().
>>>>>>>>> #ifndef PPC64
>>>>>>>>>             insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>> #else
>>>>>>>>>             if (is_field) {
>>>>>>>>>               // Add MemBarRelease for constructors which write
>>>>>>>>> volatile field
>>>>>>>>> (PPC64).
>>>>>>>>>               set_wrote_volatile(true);
>>>>>>>>>             }
>>>>>>>>> #endif
>>>>>>>>>           }
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>> the torture test suite:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>
>>>>>>>>>> Example:
>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>          __________    __________    __________    __________
>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>
>>>>>>>>>>           write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>                         read(y)                     read(x)
>>>>>>>>>>
>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>> is only
>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>> threads
>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>> sync-load-acquire
>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>
>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>
>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>> fields
>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>> published.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>> seems too
>>>>>>>>>> strong.
>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>> suffice.
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> Please review and test this change.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>          Goetz.
>>>>>>>>>>

From vladimir.kozlov at oracle.com  Thu Jan 16 00:54:57 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 16 Jan 2014 00:54:57 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52D79982.4060100@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5293F087.2080700@oracle.com>
	<5293FE15.9050100@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com>
Message-ID: <52D79E61.1060801@oracle.com>

On 1/16/14 12:34 AM, David Holmes wrote:
> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>> want to keep it this way, it could be useful to have such info on other
>> platforms too. But I would suggest to remove PPC64 comments in parse.hpp.
>>
>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>> which could be checked in all places instead of #ifdef:
>
> I asked for the ifdef some time back as I find it much preferable to have this as a build-time construct rather than a
> runtime one. I don't want to have to pay anything for this if we don't use it.

Any decent C++ compiler will optimize expressions with such constants defined in header files. I insist to avoid #ifdefs 
in C2 code. I really don't like the code with #ifdef in unsafe.cpp but I can live with it.

Vladimir

>
> David
>
>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>> #else
>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>> #endif
>>
>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>
>> and then:
>>
>>   #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>     oop p = JNIHandles::resolve(obj); \
>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>> OrderAccess::fence(); \
>>     volatile type_name v = OrderAccess::load_acquire((volatile
>> type_name*)index_oop_from_field_offset_long(p, offset));
>>
>> And:
>>
>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>> field->is_volatile()) {
>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>> +  }
>>
>> And so on. The comments will be needed only in globalDefinitions.hpp
>>
>> The code in parse1.cpp could be put on one line:
>>
>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>> method()->is_initializer()) )) {
>>
>> Thanks,
>> Vladimir
>>
>> On 1/15/14 9:25 PM, David Holmes wrote:
>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>> Hi David,
>>>>
>>>> I updated the webrev:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>
>>>> - I removed the IRIW example in parse3.cpp
>>>> - I adapted the comments not to point to that comment, and to
>>>>    reflect the new flagging.  Also I mention that we support the
>>>>    volatile constructor issue, but that it's not standard.
>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>    I also think it's better to separate these this way.
>>>
>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>> declaration and all uses to be guarded by ifdef PPC64 too
>>> please.
>>>
>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>> comment doesn't make much sense to me and refers to
>>> ppc specific stuff in a shared file:
>>>
>>>      if (is_volatile) {
>>> !     if (!is_store) {
>>>          insert_mem_bar(Op_MemBarAcquire);
>>> !     } else {
>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>          insert_mem_bar(Op_MemBarVolatile);
>>> + #endif
>>> +     }
>>>
>>> I don't think the comment is needed.
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks for your comments!
>>>>
>>>> Best regards,
>>>>    Goetz.
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>> Independent Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> Sorry for the delay in getting back to this.
>>>>
>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>> specifically it is
>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>> the commentary excessive, particularly for shared code. In particular
>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>> explanation and I don't think we need it to that level of detail. Seems
>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>
>>>> The changes related to volatile writes in the constructor, as discussed
>>>> are not required by the Java Memory Model. If you want to keep these
>>>> then I think they should all be guarded with PPC64 because it is not
>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>> PPC64 porters.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>> this version.
>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>> I also based the webrev on the latest version of the stage repo.
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>
>>>>> Best regards,
>>>>>     Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lindenmaier, Goetz
>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>> To: David Holmes
>>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>> Independent Reads of Independent Writes
>>>>>
>>>>> Hi David,
>>>>>
>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>> not
>>>>>> required to pass.
>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>> blamed on the VM if java programs are failing on PPC after they worked
>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>> it by
>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>> part is
>>>>> not that performance relevant.
>>>>>
>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>> think
>>>>> I added a compile-time guard in this new webrev:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>> several double negations I don't like, (#ifNdef
>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>> but this way I only have to change the ppc platform.
>>>>>
>>>>> Best regards,
>>>>>     Goetz
>>>>>
>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>> Independent Reads of Independent Writes
>>>>>
>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>> emails.
>>>>>
>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>> settled.
>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>
>>>>>> About our change:  David, the causality is the other way round.
>>>>>> The change is about IRIW.
>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>
>>>>> This is the part I still have some question marks over as the
>>>>> implications are not nice for performance on non-TSO platforms. But I'm
>>>>> no further along in processing that paper I'm afraid.
>>>>>
>>>>>> 2. If we do syncs before loads, we don't need to do them after stores.
>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>> constructor tests.
>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>> after stores
>>>>>>         to pass the volatile constructor tests.
>>>>>
>>>>> So we can at least undo #4 now we have established those tests were not
>>>>> required to pass.
>>>>>
>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>> order
>>>>>> instructions are not as find-granular as the
>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>> The only instruction
>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>> therefore the
>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>> proper representation
>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>> it's pointless
>>>>>> anyways.
>>>>>>
>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>> I'd be happy to add a property
>>>>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>
>>>>> A compile-time guard (ifdef) would be better than a runtime one I think
>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>> based not architecture based) as that will allows for turning this
>>>>> on/off for any architecture for testing purposes.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>> Or also
>>>>>>       OrderAccess::needs_support_iriw_ordering()
>>>>>>       VM_Version::needs_support_iriw_ordering()
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>      Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> TL;DR version:
>>>>>>
>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>> constructor-barrier
>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>> *may*
>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>> ensure
>>>>>> you can't see uninitialized fields. So the tests for this are invalid
>>>>>> and this part of the patch is not needed in general (ppc64 may need it
>>>>>> due to other factors).
>>>>>>
>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>> term :)
>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>
>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>> visible to
>>>>>> all other hardware threads at the same time point; these architectures
>>>>>> are not multiple-copy atomic."
>>>>>>
>>>>>> This is the visibility issue that I referred to and affects both
>>>>>> ARM and
>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>> current issue is what you wrote below:
>>>>>>
>>>>>>     > The fixes for the constructor issue are only needed because we
>>>>>>     > remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>     > and place it before loads.
>>>>>>
>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync after
>>>>>> the store then you have to do something around the loads to get the
>>>>>> same
>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>> only way to fix the IRIW issue was to put the fence before the load -
>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>> clearer.
>>>>>>
>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>> variables. You now want to customize that but not all the requisite
>>>>>> hooks are present. It would be better if volatile_load and
>>>>>> volatile_store were factored out so that they could be implemented as
>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>> hooks
>>>>>> that could then be customized per platform. Otherwise you need
>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>
>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>> this
>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>> abstractions are a confused mess in my opinion.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>
>>>>>>> I did not yet add the
>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>> or
>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>
>>>>>>>
>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>
>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>
>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>> store
>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>> (volatile store in constructor).
>>>>>>>
>>>>>>>
>>>>>>> @David
>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>> taskqueue problem yet,
>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>> continuous.
>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>> issue.
>>>>>>> And we came up with a solution we consider the best possible. If you
>>>>>>> have objections, you should at least give the draft of a better
>>>>>>> solution,
>>>>>>> we would volunteer to implement and test it.
>>>>>>> Similarly, we invested time in fixing the concurrency torture issues.
>>>>>>>
>>>>>>> @David
>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>> and
>>>>>>>> can't find any reference to it.
>>>>>>> We learned about this reading "A Tutorial Introduction to the ARM and
>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>> Work-Stealing for
>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>> taskqueue problem.
>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>
>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>> used 'read'
>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>> above).
>>>>>>>
>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>       Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi Goetz,
>>>>>>>
>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> -- Volatile in constuctor
>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>> missing constructor barrier.
>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>> processors
>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks Aleksey!)
>>>>>>>
>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>
>>>>>>>> -- IRIW issue
>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>> a few
>>>>>>>>> moments thought.
>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>> problem yet,
>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>
>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>> continuous.
>>>>>>>
>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>> different?)
>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>> I contributed a
>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>> nice, I admit.
>>>>>>>> (I don't really know about ARM, though).
>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>> are evaluated
>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>
>>>>>>>> The problem is not that IRIW is not handled by the JMM, the problem
>>>>>>>> is that
>>>>>>>>        store
>>>>>>>>        sync
>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>> only
>>>>>>>>        sync
>>>>>>>>        load
>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>> pass that test.
>>>>>>>
>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and
>>>>>>> can't find any reference to it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>        The JMM is fine. And
>>>>>>>>        store
>>>>>>>>        MemBarVolatile
>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>> that
>>>>>>>> do what is required.
>>>>>>>>
>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>        Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>> 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi everybody,
>>>>>>>>>
>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>
>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>> initializing
>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>> Shipilev
>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>          LongVolatileTest
>>>>>>>>>          AtomicIntegerInitialValueTest
>>>>>>>>> will fail.
>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>> volatile field would be
>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>> AtomicInteger.)
>>>>>>>>
>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>> volatiles do
>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>> that
>>>>>>>> requires the constructor barrier - discussions with Doug and Aleksey
>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>> missing constructor barrier.
>>>>>>>>
>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight
>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>> don't
>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>
>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>> OrderAccess operations
>>>>>>>>> Basically, I agree on this.  But you also have to take into account
>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>> different platforms
>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>> An example:
>>>>>>>>>         MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>         MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>> If these are consecutively in the code, sparc code looks like this:
>>>>>>>>>         MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>         MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>> Just doing what is required.
>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>> fine grained operations:
>>>>>>>>>          MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>         MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>> are more (too) powerful,
>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>> can not implement
>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>
>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable issue.
>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>> read
>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>
>>>>>>>>> I would propose to guard the code by
>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>> independent?
>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>
>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>> few
>>>>>>>> moments thought. You are implying there is a problem here that will
>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>> different?) and I can not take that on face value at the moment. The
>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>> requirements for
>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>> are not
>>>>>>>> addressed - but even then I would expect heavy barriers at the store
>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>> of the
>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>> software
>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>> don't have
>>>>>>>> that on ppc!)
>>>>>>>>
>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>> I will
>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>         Goetz.
>>>>>>>>>
>>>>>>>>> -- Other ports:
>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>> it might
>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them).
>>>>>>>>>
>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>> can
>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>> way :)
>>>>>>>>>
>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>
>>>>>>>>>        From what I understand what we see here is an attempt to
>>>>>>>>> fix an
>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>> IRIW
>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>> doing the
>>>>>>>>> load.
>>>>>>>>>
>>>>>>>>> Now if this was purely handled in ppc64 source code then I would be
>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>> performance
>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>> that
>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>> this is
>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>> with the
>>>>>>>>> taskQueue changes - these algorithms should be expressed using the
>>>>>>>>> correct OrderAccess operations to guarantee the desired properties
>>>>>>>>> independent of architecture. If such a "barrier" is not needed on a
>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>> reduce
>>>>>>>>> to a no-op.
>>>>>>>>>
>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>> under
>>>>>>>>> the JMM.
>>>>>>>>>
>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>> current
>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>> But may be it should be done using more general query which is set
>>>>>>>>>> depending on platform:
>>>>>>>>>>
>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>
>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>
>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>
>>>>>>>>> Every platform has to support IRIW this is simply part of the Java
>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>> explicitly
>>>>>>>>> like this.
>>>>>>>>>
>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are there
>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>> defines?
>>>>>>>>>>        From what I understand our ppc port is also affected.
>>>>>>>>>> David?
>>>>>>>>>
>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>> inside  else {}.
>>>>>>>>>>
>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>> specific which
>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs.
>>>>>>>>>>
>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>
>>>>>>>>>>           if (is_vol) {
>>>>>>>>>>             // See comment in do_get_xxx().
>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>             insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>> #else
>>>>>>>>>>             if (is_field) {
>>>>>>>>>>               // Add MemBarRelease for constructors which write
>>>>>>>>>> volatile field
>>>>>>>>>> (PPC64).
>>>>>>>>>>               set_wrote_volatile(true);
>>>>>>>>>>             }
>>>>>>>>>> #endif
>>>>>>>>>>           }
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>> the torture test suite:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>
>>>>>>>>>>> Example:
>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>          __________    __________    __________    __________
>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>
>>>>>>>>>>>           write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>                         read(y)                     read(x)
>>>>>>>>>>>
>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>> is only
>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>> threads
>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>
>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>
>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>> fields
>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>> published.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>> seems too
>>>>>>>>>>> strong.
>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>> suffice.
>>>>>>>>>>> What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>

From david.holmes at oracle.com  Thu Jan 16 01:04:41 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jan 2014 19:04:41 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52D79E61.1060801@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5293F087.2080700@oracle.com>
	<5293FE15.9050100@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
Message-ID: <52D7A0A9.6070208@oracle.com>

On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
> On 1/16/14 12:34 AM, David Holmes wrote:
>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>> want to keep it this way, it could be useful to have such info on other
>>> platforms too. But I would suggest to remove PPC64 comments in
>>> parse.hpp.
>>>
>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>> which could be checked in all places instead of #ifdef:
>>
>> I asked for the ifdef some time back as I find it much preferable to
>> have this as a build-time construct rather than a
>> runtime one. I don't want to have to pay anything for this if we don't
>> use it.
>
> Any decent C++ compiler will optimize expressions with such constants
> defined in header files. I insist to avoid #ifdefs in C2 code. I really
> don't like the code with #ifdef in unsafe.cpp but I can live with it.

If you insist then we may as well do it all the same way. Better to be 
consistent.

My apologies Goetz for wasting your time going back and forth on this.

That aside I have a further concern with this IRIW support - it is 
incomplete as there is no C1 support, as PPC64 isn't using client. If 
this is going on then we (which probably means the Oracle 'we') need to 
add the missing C1 code.

David
-----

> Vladimir
>
>>
>> David
>>
>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>> #else
>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>> #endif
>>>
>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>
>>> and then:
>>>
>>>   #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>     oop p = JNIHandles::resolve(obj); \
>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>> OrderAccess::fence(); \
>>>     volatile type_name v = OrderAccess::load_acquire((volatile
>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>
>>> And:
>>>
>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>> field->is_volatile()) {
>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>> +  }
>>>
>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>
>>> The code in parse1.cpp could be put on one line:
>>>
>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>> method()->is_initializer()) )) {
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>> Hi David,
>>>>>
>>>>> I updated the webrev:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>
>>>>> - I removed the IRIW example in parse3.cpp
>>>>> - I adapted the comments not to point to that comment, and to
>>>>>    reflect the new flagging.  Also I mention that we support the
>>>>>    volatile constructor issue, but that it's not standard.
>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>    I also think it's better to separate these this way.
>>>>
>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>> please.
>>>>
>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>> comment doesn't make much sense to me and refers to
>>>> ppc specific stuff in a shared file:
>>>>
>>>>      if (is_volatile) {
>>>> !     if (!is_store) {
>>>>          insert_mem_bar(Op_MemBarAcquire);
>>>> !     } else {
>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>          insert_mem_bar(Op_MemBarVolatile);
>>>> + #endif
>>>> +     }
>>>>
>>>> I don't think the comment is needed.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks for your comments!
>>>>>
>>>>> Best regards,
>>>>>    Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>> 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>> Independent Reads of Independent Writes
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> Sorry for the delay in getting back to this.
>>>>>
>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>> specifically it is
>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>> the commentary excessive, particularly for shared code. In particular
>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>> explanation and I don't think we need it to that level of detail.
>>>>> Seems
>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>
>>>>> The changes related to volatile writes in the constructor, as
>>>>> discussed
>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>> PPC64 porters.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>> this version.
>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lindenmaier, Goetz
>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>> To: David Holmes
>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>> not
>>>>>>> required to pass.
>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>> worked
>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>> it by
>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>> part is
>>>>>> not that performance relevant.
>>>>>>
>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>> think
>>>>>> I added a compile-time guard in this new webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>> several double negations I don't like, (#ifNdef
>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>> but this way I only have to change the ppc platform.
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz
>>>>>>
>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>> emails.
>>>>>>
>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>> settled.
>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>
>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>> The change is about IRIW.
>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>
>>>>>> This is the part I still have some question marks over as the
>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>> But I'm
>>>>>> no further along in processing that paper I'm afraid.
>>>>>>
>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>> stores.
>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>> constructor tests.
>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>> after stores
>>>>>>>         to pass the volatile constructor tests.
>>>>>>
>>>>>> So we can at least undo #4 now we have established those tests
>>>>>> were not
>>>>>> required to pass.
>>>>>>
>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>> order
>>>>>>> instructions are not as find-granular as the
>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>> The only instruction
>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>> therefore the
>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>> proper representation
>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>> it's pointless
>>>>>>> anyways.
>>>>>>>
>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>> I'd be happy to add a property
>>>>>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>
>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>> think
>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>> based not architecture based) as that will allows for turning this
>>>>>> on/off for any architecture for testing purposes.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>> Or also
>>>>>>>       OrderAccess::needs_support_iriw_ordering()
>>>>>>>       VM_Version::needs_support_iriw_ordering()
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> TL;DR version:
>>>>>>>
>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>> constructor-barrier
>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>> *may*
>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>> ensure
>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>> invalid
>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>> need it
>>>>>>> due to other factors).
>>>>>>>
>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>> term :)
>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>
>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>> visible to
>>>>>>> all other hardware threads at the same time point; these
>>>>>>> architectures
>>>>>>> are not multiple-copy atomic."
>>>>>>>
>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>> ARM and
>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>> current issue is what you wrote below:
>>>>>>>
>>>>>>>     > The fixes for the constructor issue are only needed because we
>>>>>>>     > remove the sync instruction from behind stores
>>>>>>> (parse3.cpp:320)
>>>>>>>     > and place it before loads.
>>>>>>>
>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>> after
>>>>>>> the store then you have to do something around the loads to get the
>>>>>>> same
>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>> load -
>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>> clearer.
>>>>>>>
>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>> volatile_store were factored out so that they could be
>>>>>>> implemented as
>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>> hooks
>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>
>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>> this
>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>
>>>>>>>> I did not yet add the
>>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>>> or
>>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>
>>>>>>>>
>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>
>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>
>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>> store
>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>> (volatile store in constructor).
>>>>>>>>
>>>>>>>>
>>>>>>>> @David
>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>> continuous.
>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>> issue.
>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>> you
>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>> solution,
>>>>>>>> we would volunteer to implement and test it.
>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>> issues.
>>>>>>>>
>>>>>>>> @David
>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>> and
>>>>>>>>> can't find any reference to it.
>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>> ARM and
>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>> Work-Stealing for
>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>> taskqueue problem.
>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>
>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>> used 'read'
>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>> above).
>>>>>>>>
>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>> missing constructor barrier.
>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>> processors
>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>> Aleksey!)
>>>>>>>>
>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>
>>>>>>>>> -- IRIW issue
>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>> a few
>>>>>>>>>> moments thought.
>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>> problem yet,
>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>
>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>> continuous.
>>>>>>>>
>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>> different?)
>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>> I contributed a
>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>> nice, I admit.
>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>> are evaluated
>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>
>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>> problem
>>>>>>>>> is that
>>>>>>>>>        store
>>>>>>>>>        sync
>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>> only
>>>>>>>>>        sync
>>>>>>>>>        load
>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>> pass that test.
>>>>>>>>
>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>> term and
>>>>>>>> can't find any reference to it.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>        The JMM is fine. And
>>>>>>>>>        store
>>>>>>>>>        MemBarVolatile
>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>> that
>>>>>>>>> do what is required.
>>>>>>>>>
>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi everybody,
>>>>>>>>>>
>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>
>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>> initializing
>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>> Shipilev
>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>          LongVolatileTest
>>>>>>>>>>          AtomicIntegerInitialValueTest
>>>>>>>>>> will fail.
>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>> volatile field would be
>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>> AtomicInteger.)
>>>>>>>>>
>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>> volatiles do
>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>> that
>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>> Aleksey
>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>> missing constructor barrier.
>>>>>>>>>
>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>> heavyweight
>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>> don't
>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>
>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>> OrderAccess operations
>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>> account
>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>> different platforms
>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>> An example:
>>>>>>>>>>         MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>         MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>> this:
>>>>>>>>>>         MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>         MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>> Just doing what is required.
>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>> fine grained operations:
>>>>>>>>>>          MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>         MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>> are more (too) powerful,
>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>> can not implement
>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>
>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>> issue.
>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>> read
>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>
>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>> independent?
>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>
>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>> few
>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>> will
>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>> moment. The
>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>> requirements for
>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>> are not
>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>> store
>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>> of the
>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>> software
>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>> don't have
>>>>>>>>> that on ppc!)
>>>>>>>>>
>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>> I will
>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>> -- Other ports:
>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>> it might
>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>> them).
>>>>>>>>>>
>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>> can
>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>> way :)
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>
>>>>>>>>>>        From what I understand what we see here is an attempt to
>>>>>>>>>> fix an
>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>> IRIW
>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>> doing the
>>>>>>>>>> load.
>>>>>>>>>>
>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>> would be
>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>> performance
>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>> that
>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>> this is
>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>> with the
>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>> the
>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>> properties
>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>> on a
>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>> reduce
>>>>>>>>>> to a no-op.
>>>>>>>>>>
>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>> under
>>>>>>>>>> the JMM.
>>>>>>>>>>
>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>> current
>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>> is set
>>>>>>>>>>> depending on platform:
>>>>>>>>>>>
>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>
>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>
>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>> Java
>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>> explicitly
>>>>>>>>>> like this.
>>>>>>>>>>
>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>> there
>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>> defines?
>>>>>>>>>>>        From what I understand our ppc port is also affected.
>>>>>>>>>>> David?
>>>>>>>>>>
>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>
>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>> specific which
>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>
>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>
>>>>>>>>>>>           if (is_vol) {
>>>>>>>>>>>             // See comment in do_get_xxx().
>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>             insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>> #else
>>>>>>>>>>>             if (is_field) {
>>>>>>>>>>>               // Add MemBarRelease for constructors which write
>>>>>>>>>>> volatile field
>>>>>>>>>>> (PPC64).
>>>>>>>>>>>               set_wrote_volatile(true);
>>>>>>>>>>>             }
>>>>>>>>>>> #endif
>>>>>>>>>>>           }
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Vladimir
>>>>>>>>>>>
>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> Example:
>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>          __________    __________    __________    __________
>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>
>>>>>>>>>>>>           write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>                         read(y)                     read(x)
>>>>>>>>>>>>
>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>> is only
>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>> threads
>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>
>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>
>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>> fields
>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>> published.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>> seems too
>>>>>>>>>>>> strong.
>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>> suffice.
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz.
>>>>>>>>>>>>

From vladimir.kozlov at oracle.com  Thu Jan 16 10:15:39 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 16 Jan 2014 10:15:39 -0800
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <52D76E6F.8070504@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>
	<52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com>
Message-ID: <52D821CB.6020207@oracle.com>

Changes are in C++ Interpreter so it does not affect Oracle VM.
But David has point here. I would like to hear the explanation too.

BTW, I see that for ppc64:

src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);

as result write_memory_serialize_page() is used in 
ThreadStateTransition::transition().

Is it not enough on PPC64?

Thanks,
Vladimir

On 1/15/14 9:30 PM, David Holmes wrote:
> Can I get some response on this please - specifically the redundancy wrt
> IRT_ENTRY actions.
>
> Thanks,
> David
>
> On 20/12/2013 11:55 AM, David Holmes wrote:
>> Still catching up ...
>>
>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> this change adds StoreStore barriers after object initialization and
>>> after constructor calls in the C++ interpreter.  This assures no
>>> uninitialized
>>> objects or final fields are visible.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>
>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>> thread state transitions that already include a full "fence" so the
>> storestore barriers are redundant in those cases.
>>
>> The fastpath _new storestore seems okay.
>>
>> I don't know how handle_return gets used to know if it is reasonable or
>> not.
>>
>> I was trying, unsuccessfully, to examine the same code in the
>> templateInterpreter to see how it handles these cases as it naturally
>> has the same object-initialization-safety requirements (though these can
>> be handled in a number of different ways other than an unconditional
>> storestore barrier at the end of the initialization and construction
>> phases.
>>
>> David
>> -----
>>
>>> Please review and test this change.
>>>
>>> Best regards,
>>>    Goetz.
>>>

From alejandro.murillo at oracle.com  Thu Jan 16 13:18:16 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Thu, 16 Jan 2014 21:18:16 +0000
Subject: hg: hsx/jdk7u/hotspot: 3 new changesets
Message-ID: <20140116211825.4BF6E624E2@hg.openjdk.java.net>

Changeset: a3cb61e9abbc
Author:    ccheung
Date:      2013-07-17 12:22 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a3cb61e9abbc

8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20
Summary: Added (sig < MAXSIGNUM) check in jsig.c
Reviewed-by: dholmes, acorn

! src/os/linux/vm/jsig.c
+ test/runtime/jsig/Test8017498.sh
+ test/runtime/jsig/TestJNI.c
+ test/runtime/jsig/TestJNI.java

Changeset: 90cc2265078e
Author:    ccheung
Date:      2013-07-19 14:54 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/90cc2265078e

8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code
Summary: Added -DLINUX to the gcc command and improved the .sh script
Reviewed-by: dcubed, dholmes, minqi

! test/runtime/jsig/Test8017498.sh
! test/runtime/jsig/TestJNI.c

Changeset: 3ff8394ad1fa
Author:    ccheung
Date:      2013-07-30 14:14 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/3ff8394ad1fa

8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases
Summary: Added checking for gcc and simplified the sig_handler() in the test case
Reviewed-by: dcubed, coleenp, minqi, dlong

! test/runtime/6929067/Test6929067.sh
! test/runtime/7107135/Test7107135.sh
! test/runtime/jsig/Test8017498.sh
! test/runtime/jsig/TestJNI.c


From alejandro.murillo at oracle.com  Thu Jan 16 16:52:22 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 17 Jan 2014 00:52:22 +0000
Subject: hg: hsx/jdk7u/hotspot: 44 new changesets
Message-ID: <20140117005406.75782624F1@hg.openjdk.java.net>

Changeset: ca681a7f3a26
Author:    asaha
Date:      2013-09-12 08:08 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ca681a7f3a26

Merge

! .hgtags
! make/hotspot_version

Changeset: 962bde0be11c
Author:    coleenp
Date:      2013-09-16 14:22 -0400
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/962bde0be11c

8021271: Better buffering in ObjC code
Summary: Improve buffering in ObjC code
Reviewed-by: serb, hseigel, coleenp
Contributed-by: gerard.ziemski at oracle.com

! src/share/vm/runtime/os.cpp

Changeset: 143a99671e52
Author:    asaha
Date:      2013-09-18 11:17 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/143a99671e52

Merge

! .hgtags

Changeset: af92fd5e046e
Author:    asaha
Date:      2013-09-18 11:30 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/af92fd5e046e

Merge

! .hgtags

Changeset: ab8db063dccc
Author:    asaha
Date:      2013-09-19 15:31 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ab8db063dccc

Merge

! .hgtags

Changeset: 8e077c93ab9a
Author:    asaha
Date:      2013-09-24 10:52 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/8e077c93ab9a

Merge

! .hgtags

Changeset: 129a5092d628
Author:    asaha
Date:      2013-09-26 11:23 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/129a5092d628

Merge

! .hgtags

Changeset: 0d4045749f28
Author:    asaha
Date:      2013-09-27 12:15 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/0d4045749f28

Merge

! .hgtags

Changeset: 45820ef2222f
Author:    asaha
Date:      2013-09-27 13:16 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/45820ef2222f

Merge

! .hgtags

Changeset: fa74e40ea420
Author:    asaha
Date:      2013-09-30 10:59 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/fa74e40ea420

Added tag jdk7u51-b00 for changeset 429884602206

! .hgtags

Changeset: a9dcf7edc696
Author:    asaha
Date:      2013-09-30 11:12 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a9dcf7edc696

Merge

! .hgtags

Changeset: 68f03ff066f2
Author:    asaha
Date:      2013-09-30 11:23 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/68f03ff066f2

8025679: Increment minor version of HSx for 7u51 and initialize the build number
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68c42e105b90
Author:    cl
Date:      2013-10-01 08:36 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/68c42e105b90

Added tag jdk7u51-b01 for changeset 68f03ff066f2

! .hgtags

Changeset: 050690eaebec
Author:    asaha
Date:      2013-10-08 11:49 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/050690eaebec

Merge

! .hgtags

Changeset: 67910a581eca
Author:    asaha
Date:      2013-10-09 09:50 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/67910a581eca

Merge

! .hgtags

Changeset: 4138fb11955a
Author:    cl
Date:      2013-10-10 10:16 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4138fb11955a

Added tag jdk7u51-b02 for changeset 67910a581eca

! .hgtags

Changeset: 683458c333ce
Author:    cl
Date:      2013-10-15 09:31 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/683458c333ce

Added tag jdk7u51-b03 for changeset 4138fb11955a

! .hgtags

Changeset: ed2db7a82229
Author:    cl
Date:      2013-10-22 22:23 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ed2db7a82229

Added tag jdk7u51-b04 for changeset 683458c333ce

! .hgtags

Changeset: fec027762cf3
Author:    cl
Date:      2013-10-29 09:08 -0700
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/fec027762cf3

Added tag jdk7u51-b05 for changeset ed2db7a82229

! .hgtags

Changeset: 18c14aa176b3
Author:    cl
Date:      2013-11-05 10:58 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/18c14aa176b3

Added tag jdk7u51-b06 for changeset fec027762cf3

! .hgtags

Changeset: eb486a2ec09b
Author:    asaha
Date:      2013-11-06 14:47 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/eb486a2ec09b

8027944: Increment hsx 24.51 build to b02 for 7u51-b07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: f673c581ebf9
Author:    aeriksso
Date:      2013-10-31 16:49 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f673c581ebf9

8026887: Make issues due to failed large pages allocations easier to debug
Reviewed-by: stefank, mcastegr, poonam

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: b0a355aae004
Author:    cl
Date:      2013-11-12 08:51 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b0a355aae004

Added tag jdk7u51-b07 for changeset f673c581ebf9

! .hgtags

Changeset: 4f56f2e206fd
Author:    cl
Date:      2013-11-19 08:36 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4f56f2e206fd

Added tag jdk7u51-b08 for changeset b0a355aae004

! .hgtags

Changeset: 1b7aaef3df78
Author:    asaha
Date:      2013-11-27 08:20 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1b7aaef3df78

Added tag jdk7u51-b09 for changeset 4f56f2e206fd

! .hgtags

Changeset: 0cff26632b96
Author:    katleman
Date:      2013-12-04 10:11 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/0cff26632b96

Added tag jdk7u51-b10 for changeset 1b7aaef3df78

! .hgtags

Changeset: 839100e42498
Author:    jrose
Date:      2013-12-05 14:38 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/839100e42498

8029507: Enhance JVM method processing
8029533: REGRESSION: closed/java/lang/invoke/8008140/Test8008140.java fails against JPRT PIT 17891982 build
8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName
Reviewed-by: acorn, vlivanov

! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/reflection.cpp

Changeset: 1f11dff734af
Author:    asaha
Date:      2013-12-09 13:55 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1f11dff734af

8029842: Increment hsx 24.51 build to b03 for 7u51-b11
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: dee2a38ef6b2
Author:    katleman
Date:      2013-12-10 13:15 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/dee2a38ef6b2

Added tag jdk7u51-b11 for changeset 1f11dff734af

! .hgtags

Changeset: 6c6a2299029a
Author:    katleman
Date:      2013-12-14 11:51 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/6c6a2299029a

Added tag jdk7u51-b12 for changeset dee2a38ef6b2

! .hgtags

Changeset: 0bcb43482f2a
Author:    cl
Date:      2013-11-25 11:02 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/0bcb43482f2a

Added tag jdk7u45-b33 for changeset c373a733d5d5

! .hgtags

Changeset: 12ea8d416f10
Author:    katleman
Date:      2013-12-06 13:07 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/12ea8d416f10

Added tag jdk7u45-b34 for changeset 0bcb43482f2a

! .hgtags

Changeset: d9ac18d080af
Author:    asaha
Date:      2013-12-17 11:06 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d9ac18d080af

Merge

! .hgtags

Changeset: a398ddc79d23
Author:    katleman
Date:      2013-12-19 09:00 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a398ddc79d23

Added tag jdk7u51-b13 for changeset 6c6a2299029a

! .hgtags

Changeset: cf4110c35afb
Author:    asaha
Date:      2013-12-19 09:32 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/cf4110c35afb

Merge

! .hgtags

Changeset: 208dbfe8ac03
Author:    katleman
Date:      2013-12-20 18:52 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/208dbfe8ac03

Added tag jdk7u51-b31 for changeset cf4110c35afb

! .hgtags

Changeset: 90931375569a
Author:    katleman
Date:      2013-12-26 13:04 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/90931375569a

Added tag jdk7u51-b30 for changeset a398ddc79d23

! .hgtags

Changeset: f8a1ba5693e9
Author:    asaha
Date:      2013-12-31 08:56 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f8a1ba5693e9

Merge

! .hgtags

Changeset: 91d016d56832
Author:    asaha
Date:      2014-01-02 09:34 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/91d016d56832

Merge

! .hgtags
! make/hotspot_version
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 50f489feeb5e
Author:    asaha
Date:      2014-01-15 10:45 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/50f489feeb5e

8031787: Remove fix JDK-8026887 from 7u60
Summary: Backed out changeset f673c581ebf9
Reviewed-by: coffeys

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 2c971ed884ce
Author:    asaha
Date:      2014-01-15 10:53 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2c971ed884ce

Merge

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 09e3feebb48f
Author:    katleman
Date:      2014-01-16 11:51 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/09e3feebb48f

Added tag jdk7u60-b03 for changeset 2c971ed884ce

! .hgtags

Changeset: 1afbeb8cb558
Author:    amurillo
Date:      2014-01-16 14:52 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1afbeb8cb558

Merge

! make/hotspot_version

Changeset: 05fe7a87d149
Author:    amurillo
Date:      2014-01-16 14:52 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/05fe7a87d149

Added tag hs24.60-b07 for changeset 1afbeb8cb558

! .hgtags


From christian.thalinger at oracle.com  Thu Jan 16 17:40:07 2014
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Fri, 17 Jan 2014 01:40:07 +0000
Subject: hg: hsx/hotspot-main/hotspot: 8022395: java.util.zip.ZipException:
	Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests
Message-ID: <20140117014012.AAB21624FC@hg.openjdk.java.net>

Changeset: 8b81451dc7f7
Author:    twisti
Date:      2014-01-16 16:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b81451dc7f7

8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp


From alejandro.murillo at oracle.com  Thu Jan 16 18:10:40 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 17 Jan 2014 02:10:40 +0000
Subject: hg: hsx/jdk7u/hotspot: 8032013: new hotspot build - hs24.60-b08
Message-ID: <20140117021042.A8C28624FF@hg.openjdk.java.net>

Changeset: 4f390a6d423b
Author:    amurillo
Date:      2014-01-16 14:58 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4f390a6d423b

8032013: new hotspot build - hs24.60-b08
Reviewed-by: jcoomes

! make/hotspot_version


From mike.duigou at oracle.com  Thu Jan 16 18:18:59 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 16 Jan 2014 18:18:59 -0800
Subject: RFR: 8030350: Enable additional compiler warnings for GCC
Message-ID: <86B8D7B3-7968-4101-8A15-E0A62646A975@oracle.com>

Hello all;

I've done some additional testing of my previous patch enabling additional GCC warnings for native code.

http://cr.openjdk.java.net/~mduigou/JDK-8030350/4/webrev/

With the switch to -Wformat=2 I found it necessary to add -Wno-error=format-nonliteral for hotspot as there are legitimate calls to sscanf that use a passed parameter.

In addition to review I still need a sponsor to push this to hotspot for me.

Thanks,

Mike


From david.holmes at oracle.com  Thu Jan 16 18:21:11 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Jan 2014 12:21:11 +1000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <52D821CB.6020207@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>
	<52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com>
	<52D821CB.6020207@oracle.com>
Message-ID: <52D89397.2030903@oracle.com>

On 17/01/2014 4:15 AM, Vladimir Kozlov wrote:
> Changes are in C++ Interpreter so it does not affect Oracle VM.
> But David has point here. I would like to hear the explanation too.
>
> BTW, I see that for ppc64:
>
> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>
> as result write_memory_serialize_page() is used in
> ThreadStateTransition::transition().
>
> Is it not enough on PPC64?

You would need to consult a PPC64+linux expert to be certain but what I 
was basically told is that the serialization page mechanism is only 
guaranteed to work for TSO systems.

David
-----


> Thanks,
> Vladimir
>
> On 1/15/14 9:30 PM, David Holmes wrote:
>> Can I get some response on this please - specifically the redundancy wrt
>> IRT_ENTRY actions.
>>
>> Thanks,
>> David
>>
>> On 20/12/2013 11:55 AM, David Holmes wrote:
>>> Still catching up ...
>>>
>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> this change adds StoreStore barriers after object initialization and
>>>> after constructor calls in the C++ interpreter.  This assures no
>>>> uninitialized
>>>> objects or final fields are visible.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>>
>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>>> thread state transitions that already include a full "fence" so the
>>> storestore barriers are redundant in those cases.
>>>
>>> The fastpath _new storestore seems okay.
>>>
>>> I don't know how handle_return gets used to know if it is reasonable or
>>> not.
>>>
>>> I was trying, unsuccessfully, to examine the same code in the
>>> templateInterpreter to see how it handles these cases as it naturally
>>> has the same object-initialization-safety requirements (though these can
>>> be handled in a number of different ways other than an unconditional
>>> storestore barrier at the end of the initialization and construction
>>> phases.
>>>
>>> David
>>> -----
>>>
>>>> Please review and test this change.
>>>>
>>>> Best regards,
>>>>    Goetz.
>>>>

From goetz.lindenmaier at sap.com  Fri Jan 17 00:39:05 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Jan 2014 08:39:05 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52D7A0A9.6070208@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>

Hi,

I tried to come up with a webrev that implements the change as proposed in 
your mails:
http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/

Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use 
support_IRIW_for_not_multiple_copy_atomic_cpu.

I left the definition and handling of _wrote_volatile in the code, without
any protection.
I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
and put it on one line.

I removed the comment in library_call.cpp.
I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
from the comments as it's PPC specific.

Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these 
issues in C1 if nobody did it by then.

Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
performance problems arise, we still can add #ifdef PPC64 to circumvent this.

Best regards,
  Goetz.



-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Donnerstag, 16. Januar 2014 10:05
To: Vladimir Kozlov
Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
> On 1/16/14 12:34 AM, David Holmes wrote:
>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>> want to keep it this way, it could be useful to have such info on other
>>> platforms too. But I would suggest to remove PPC64 comments in
>>> parse.hpp.
>>>
>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>> which could be checked in all places instead of #ifdef:
>>
>> I asked for the ifdef some time back as I find it much preferable to
>> have this as a build-time construct rather than a
>> runtime one. I don't want to have to pay anything for this if we don't
>> use it.
>
> Any decent C++ compiler will optimize expressions with such constants
> defined in header files. I insist to avoid #ifdefs in C2 code. I really
> don't like the code with #ifdef in unsafe.cpp but I can live with it.

If you insist then we may as well do it all the same way. Better to be 
consistent.

My apologies Goetz for wasting your time going back and forth on this.

That aside I have a further concern with this IRIW support - it is 
incomplete as there is no C1 support, as PPC64 isn't using client. If 
this is going on then we (which probably means the Oracle 'we') need to 
add the missing C1 code.

David
-----

> Vladimir
>
>>
>> David
>>
>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>> #else
>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>> #endif
>>>
>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>
>>> and then:
>>>
>>>   #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>     oop p = JNIHandles::resolve(obj); \
>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>> OrderAccess::fence(); \
>>>     volatile type_name v = OrderAccess::load_acquire((volatile
>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>
>>> And:
>>>
>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>> field->is_volatile()) {
>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>> +  }
>>>
>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>
>>> The code in parse1.cpp could be put on one line:
>>>
>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>> method()->is_initializer()) )) {
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>> Hi David,
>>>>>
>>>>> I updated the webrev:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>
>>>>> - I removed the IRIW example in parse3.cpp
>>>>> - I adapted the comments not to point to that comment, and to
>>>>>    reflect the new flagging.  Also I mention that we support the
>>>>>    volatile constructor issue, but that it's not standard.
>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>    I also think it's better to separate these this way.
>>>>
>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>> please.
>>>>
>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>> comment doesn't make much sense to me and refers to
>>>> ppc specific stuff in a shared file:
>>>>
>>>>      if (is_volatile) {
>>>> !     if (!is_store) {
>>>>          insert_mem_bar(Op_MemBarAcquire);
>>>> !     } else {
>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>          insert_mem_bar(Op_MemBarVolatile);
>>>> + #endif
>>>> +     }
>>>>
>>>> I don't think the comment is needed.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks for your comments!
>>>>>
>>>>> Best regards,
>>>>>    Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>> 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>> Independent Reads of Independent Writes
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> Sorry for the delay in getting back to this.
>>>>>
>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>> specifically it is
>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>> the commentary excessive, particularly for shared code. In particular
>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>> explanation and I don't think we need it to that level of detail.
>>>>> Seems
>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>
>>>>> The changes related to volatile writes in the constructor, as
>>>>> discussed
>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>> PPC64 porters.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>> this version.
>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lindenmaier, Goetz
>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>> To: David Holmes
>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>> not
>>>>>>> required to pass.
>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>> worked
>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>> it by
>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>> part is
>>>>>> not that performance relevant.
>>>>>>
>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>> think
>>>>>> I added a compile-time guard in this new webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>> several double negations I don't like, (#ifNdef
>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>> but this way I only have to change the ppc platform.
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz
>>>>>>
>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>> emails.
>>>>>>
>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>> settled.
>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>
>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>> The change is about IRIW.
>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>
>>>>>> This is the part I still have some question marks over as the
>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>> But I'm
>>>>>> no further along in processing that paper I'm afraid.
>>>>>>
>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>> stores.
>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>> constructor tests.
>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>> after stores
>>>>>>>         to pass the volatile constructor tests.
>>>>>>
>>>>>> So we can at least undo #4 now we have established those tests
>>>>>> were not
>>>>>> required to pass.
>>>>>>
>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>> order
>>>>>>> instructions are not as find-granular as the
>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>> The only instruction
>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>> therefore the
>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>> proper representation
>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>> it's pointless
>>>>>>> anyways.
>>>>>>>
>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>> I'd be happy to add a property
>>>>>>>      OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>
>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>> think
>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>> based not architecture based) as that will allows for turning this
>>>>>> on/off for any architecture for testing purposes.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>> Or also
>>>>>>>       OrderAccess::needs_support_iriw_ordering()
>>>>>>>       VM_Version::needs_support_iriw_ordering()
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> TL;DR version:
>>>>>>>
>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>> constructor-barrier
>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>> *may*
>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>> ensure
>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>> invalid
>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>> need it
>>>>>>> due to other factors).
>>>>>>>
>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>> term :)
>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>
>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>> visible to
>>>>>>> all other hardware threads at the same time point; these
>>>>>>> architectures
>>>>>>> are not multiple-copy atomic."
>>>>>>>
>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>> ARM and
>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>> current issue is what you wrote below:
>>>>>>>
>>>>>>>     > The fixes for the constructor issue are only needed because we
>>>>>>>     > remove the sync instruction from behind stores
>>>>>>> (parse3.cpp:320)
>>>>>>>     > and place it before loads.
>>>>>>>
>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>> after
>>>>>>> the store then you have to do something around the loads to get the
>>>>>>> same
>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>> load -
>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>> clearer.
>>>>>>>
>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>> volatile_store were factored out so that they could be
>>>>>>> implemented as
>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>> hooks
>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>
>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>> this
>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>
>>>>>>>> I did not yet add the
>>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>>> or
>>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>
>>>>>>>>
>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>
>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>
>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>> store
>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>> (volatile store in constructor).
>>>>>>>>
>>>>>>>>
>>>>>>>> @David
>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>> continuous.
>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>> issue.
>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>> you
>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>> solution,
>>>>>>>> we would volunteer to implement and test it.
>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>> issues.
>>>>>>>>
>>>>>>>> @David
>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>> and
>>>>>>>>> can't find any reference to it.
>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>> ARM and
>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>> Work-Stealing for
>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>> taskqueue problem.
>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>
>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>> used 'read'
>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>> above).
>>>>>>>>
>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>> missing constructor barrier.
>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>> processors
>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>> Aleksey!)
>>>>>>>>
>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>
>>>>>>>>> -- IRIW issue
>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>> a few
>>>>>>>>>> moments thought.
>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>> problem yet,
>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>
>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>> continuous.
>>>>>>>>
>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>> different?)
>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>> I contributed a
>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>> nice, I admit.
>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>> are evaluated
>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>
>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>> problem
>>>>>>>>> is that
>>>>>>>>>        store
>>>>>>>>>        sync
>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>> only
>>>>>>>>>        sync
>>>>>>>>>        load
>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>> pass that test.
>>>>>>>>
>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>> term and
>>>>>>>> can't find any reference to it.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>        The JMM is fine. And
>>>>>>>>>        store
>>>>>>>>>        MemBarVolatile
>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>> that
>>>>>>>>> do what is required.
>>>>>>>>>
>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi everybody,
>>>>>>>>>>
>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>
>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>> initializing
>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>> Shipilev
>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>          LongVolatileTest
>>>>>>>>>>          AtomicIntegerInitialValueTest
>>>>>>>>>> will fail.
>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>> volatile field would be
>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>> AtomicInteger.)
>>>>>>>>>
>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>> volatiles do
>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>> that
>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>> Aleksey
>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>> missing constructor barrier.
>>>>>>>>>
>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>> heavyweight
>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>> don't
>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>
>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>> OrderAccess operations
>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>> account
>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>> different platforms
>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>> An example:
>>>>>>>>>>         MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>         MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>> this:
>>>>>>>>>>         MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>         MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>> Just doing what is required.
>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>> fine grained operations:
>>>>>>>>>>          MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>         MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>> are more (too) powerful,
>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>> can not implement
>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>
>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>> issue.
>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>> read
>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>
>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>> independent?
>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>
>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>> few
>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>> will
>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>> moment. The
>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>> requirements for
>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>> are not
>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>> store
>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>> of the
>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>> software
>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>> don't have
>>>>>>>>> that on ppc!)
>>>>>>>>>
>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>> I will
>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>> -- Other ports:
>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>> it might
>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>> them).
>>>>>>>>>>
>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>> can
>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>> way :)
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>
>>>>>>>>>>        From what I understand what we see here is an attempt to
>>>>>>>>>> fix an
>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>> IRIW
>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>> doing the
>>>>>>>>>> load.
>>>>>>>>>>
>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>> would be
>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>> performance
>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>> that
>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>> this is
>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>> with the
>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>> the
>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>> properties
>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>> on a
>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>> reduce
>>>>>>>>>> to a no-op.
>>>>>>>>>>
>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>> under
>>>>>>>>>> the JMM.
>>>>>>>>>>
>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>> current
>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>> is set
>>>>>>>>>>> depending on platform:
>>>>>>>>>>>
>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>
>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>
>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>> Java
>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>> explicitly
>>>>>>>>>> like this.
>>>>>>>>>>
>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>> there
>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>> defines?
>>>>>>>>>>>        From what I understand our ppc port is also affected.
>>>>>>>>>>> David?
>>>>>>>>>>
>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>
>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>> specific which
>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>
>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>
>>>>>>>>>>>           if (is_vol) {
>>>>>>>>>>>             // See comment in do_get_xxx().
>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>             insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>> #else
>>>>>>>>>>>             if (is_field) {
>>>>>>>>>>>               // Add MemBarRelease for constructors which write
>>>>>>>>>>> volatile field
>>>>>>>>>>> (PPC64).
>>>>>>>>>>>               set_wrote_volatile(true);
>>>>>>>>>>>             }
>>>>>>>>>>> #endif
>>>>>>>>>>>           }
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Vladimir
>>>>>>>>>>>
>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> Example:
>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>          __________    __________    __________    __________
>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>
>>>>>>>>>>>>           write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>                         read(y)                     read(x)
>>>>>>>>>>>>
>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>> is only
>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>> threads
>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>
>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>
>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>> fields
>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>> published.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>> seems too
>>>>>>>>>>>> strong.
>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>> suffice.
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz.
>>>>>>>>>>>>

From goetz.lindenmaier at sap.com  Fri Jan 17 05:30:23 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Jan 2014 13:30:23 +0000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <52D821CB.6020207@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>
	<52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com>
	<52D821CB.6020207@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>

Hi,

I had a look at the first part of this issue: Whether StoreStore 
is necessary in the interpreter.  Let's for now assume the serialization
page mechanism works on PPC.

In the state transition leaving the VM state, which is executed in the
destructor, ThreadStateTransition::transition() is called, which executes
      if (UseMembar) {
        OrderAccess::fence();
      } else {
        os::write_memory_serialize_page(thread);
      }

os:: write_memory_serialize_page() can not be considered a proper
MemBar, as it only serializes if another thread poisoned the page.
Thus it does not qualify to order the initialization and the publishing
of the object.

You are right, if UseMembar is true, the StoreStore in the interpreter
is superfluous.  We could guard the StoreStores in the interpreter by
!UseMembar.

But then again, one is to order the publishing of the thread states, 
the other to enforce some Java semantics.  I don't know whether everybody
who changes in one place is aware of both issues.  But if you want to,
I'll add a !UseMembar in the interpreter.  Maybe it would be a good idea
to document the double use in interfaceSupport.cpp, too.  And maybe 
add an assertion of some kind.

We're digging into the other issue currenty, whether the serialization page
works on ppc.  We understand your concerns and have no simple answer to 
it right now.  At least, in our VM and in the port there are no known problems
with the state transitions.

Best regards,
  Goetz.



-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Donnerstag, 16. Januar 2014 19:16
To: David Holmes; Lindenmaier, Goetz
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization

Changes are in C++ Interpreter so it does not affect Oracle VM.
But David has point here. I would like to hear the explanation too.

BTW, I see that for ppc64:

src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);

as result write_memory_serialize_page() is used in 
ThreadStateTransition::transition().

Is it not enough on PPC64?

Thanks,
Vladimir

On 1/15/14 9:30 PM, David Holmes wrote:
> Can I get some response on this please - specifically the redundancy wrt
> IRT_ENTRY actions.
>
> Thanks,
> David
>
> On 20/12/2013 11:55 AM, David Holmes wrote:
>> Still catching up ...
>>
>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> this change adds StoreStore barriers after object initialization and
>>> after constructor calls in the C++ interpreter.  This assures no
>>> uninitialized
>>> objects or final fields are visible.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>
>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>> thread state transitions that already include a full "fence" so the
>> storestore barriers are redundant in those cases.
>>
>> The fastpath _new storestore seems okay.
>>
>> I don't know how handle_return gets used to know if it is reasonable or
>> not.
>>
>> I was trying, unsuccessfully, to examine the same code in the
>> templateInterpreter to see how it handles these cases as it naturally
>> has the same object-initialization-safety requirements (though these can
>> be handled in a number of different ways other than an unconditional
>> storestore barrier at the end of the initialization and construction
>> phases.
>>
>> David
>> -----
>>
>>> Please review and test this change.
>>>
>>> Best regards,
>>>    Goetz.
>>>

From harold.seigel at oracle.com  Fri Jan 17 11:29:24 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 17 Jan 2014 14:29:24 -0500
Subject: RFR(S) 8030955:  assert(_prologue != NULL) failed: prologue pointer
	must be initialized
Message-ID: <52D98494.2060100@oracle.com>

Hi,

Please review this backport to JDK8u of the JDK 9 hotspot fix for bug 
JDK-8030955.  This backport was tested with the jtreg hotspot tests, ute 
quick tests, and the accompanying test.

The bug: https://bugs.openjdk.java.net/browse/JDK-8030955
Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8030955_8u/

Thanks! Harold

From calvin.cheung at oracle.com  Fri Jan 17 11:57:41 2014
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 17 Jan 2014 11:57:41 -0800
Subject: RFR(S) 8030955: assert(_prologue != NULL) failed: prologue pointer
	must be initialized
In-Reply-To: <52D98494.2060100@oracle.com>
References: <52D98494.2060100@oracle.com>
Message-ID: <52D98B35.7040507@oracle.com>

Harold,

The backport looks good.
One nit: I don't think you need the following import in the test case.
32 import java.io.File;
33 import java.util.Map;

Calvin

On 1/17/2014 11:29 AM, harold seigel wrote:
> Hi,
>
> Please review this backport to JDK8u of the JDK 9 hotspot fix for bug 
> JDK-8030955.  This backport was tested with the jtreg hotspot tests, 
> ute quick tests, and the accompanying test.
>
> The bug: https://bugs.openjdk.java.net/browse/JDK-8030955
> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8030955_8u/
>
> Thanks! Harold


From henry.jen at oracle.com  Fri Jan 17 12:03:42 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 17 Jan 2014 12:03:42 -0800
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make 4.0
	with -I<path contains j>
Message-ID: <52D98C9E.8070906@oracle.com>

Hi,

This is a follow up on an issue first reported on Nov. 2, the fix had 
been discussed at that time[1] and works for me.

The issue is that the sed command in adjust-mflags.sh trying to isolate 
-j switch failed to deal with new MFLAGS format spitted out by gmake 4, 
where the -I<path> without a space, and so if the path contains 'j', the 
script is confused.

Here is a webrev for JDK9,
http://cr.openjdk.java.net/~henryjen/jdk9/8028407/0/

Would like to have a sponsor review and push the change, I am tired of 
patching this. :)

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011692.html

Cheers,
Henry

From coleen.phillimore at oracle.com  Fri Jan 17 14:12:50 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 17 Jan 2014 17:12:50 -0500
Subject: RFR(S) 8030955: assert(_prologue != NULL) failed: prologue pointer
	must be initialized
In-Reply-To: <52D98B35.7040507@oracle.com>
References: <52D98494.2060100@oracle.com> <52D98B35.7040507@oracle.com>
Message-ID: <52D9AAE2.6090508@oracle.com>

On 1/17/2014 2:57 PM, Calvin Cheung wrote:
> Harold,
>
> The backport looks good.
> One nit: I don't think you need the following import in the test case.
> 32 import java.io.File;
> 33 import java.util.Map;

The backport looks good.   If the jdk9 test case has these imports, I 
think you should leave them in the backport for consistency.
Coleen

>
> Calvin
>
> On 1/17/2014 11:29 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this backport to JDK8u of the JDK 9 hotspot fix for bug 
>> JDK-8030955.  This backport was tested with the jtreg hotspot tests, 
>> ute quick tests, and the accompanying test.
>>
>> The bug: https://bugs.openjdk.java.net/browse/JDK-8030955
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8030955_8u/
>>
>> Thanks! Harold
>


From vladimir.kozlov at oracle.com  Fri Jan 17 17:05:35 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 17 Jan 2014 17:05:35 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5293FE15.9050100@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
Message-ID: <52D9D35F.2050501@oracle.com>

Goetz,

I asked to remove both comments in parse.hpp, comments in parse1.cpp and 
parse3.cpp is enough. It should be similar to _wrote_final:

    bool          _wrote_volatile;   // Did we write a final field?


I think the next comment in parse3.cpp should be modified:

+    // But remember we wrote a volatile field so that a barrier can be 
issued
+    // in constructors. See do_exits() in parse1.cpp.

// Remember we wrote a volatile field.
// For not multiple copy atomic cpu (ppc64) a barrier should be issued
// in constructors which have such stores. See do_exits() in parse1.cpp.

Thanks,
Vladimir

On 1/17/14 12:39 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I tried to come up with a webrev that implements the change as proposed in
> your mails:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>
> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
> support_IRIW_for_not_multiple_copy_atomic_cpu.
>
> I left the definition and handling of _wrote_volatile in the code, without
> any protection.
> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
> and put it on one line.
>
> I removed the comment in library_call.cpp.
> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
> from the comments as it's PPC specific.
>
> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
> issues in C1 if nobody did it by then.
>
> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>
> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 16. Januar 2014 10:05
> To: Vladimir Kozlov
> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>> On 1/16/14 12:34 AM, David Holmes wrote:
>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>> want to keep it this way, it could be useful to have such info on other
>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>> parse.hpp.
>>>>
>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>> which could be checked in all places instead of #ifdef:
>>>
>>> I asked for the ifdef some time back as I find it much preferable to
>>> have this as a build-time construct rather than a
>>> runtime one. I don't want to have to pay anything for this if we don't
>>> use it.
>>
>> Any decent C++ compiler will optimize expressions with such constants
>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>
> If you insist then we may as well do it all the same way. Better to be
> consistent.
>
> My apologies Goetz for wasting your time going back and forth on this.
>
> That aside I have a further concern with this IRIW support - it is
> incomplete as there is no C1 support, as PPC64 isn't using client. If
> this is going on then we (which probably means the Oracle 'we') need to
> add the missing C1 code.
>
> David
> -----
>
>> Vladimir
>>
>>>
>>> David
>>>
>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>> #else
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>> #endif
>>>>
>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>
>>>> and then:
>>>>
>>>>    #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>      oop p = JNIHandles::resolve(obj); \
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>> OrderAccess::fence(); \
>>>>      volatile type_name v = OrderAccess::load_acquire((volatile
>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>
>>>> And:
>>>>
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>> field->is_volatile()) {
>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>> +  }
>>>>
>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>
>>>> The code in parse1.cpp could be put on one line:
>>>>
>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>> method()->is_initializer()) )) {
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> I updated the webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>
>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>     reflect the new flagging.  Also I mention that we support the
>>>>>>     volatile constructor issue, but that it's not standard.
>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>     I also think it's better to separate these this way.
>>>>>
>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>> please.
>>>>>
>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>> comment doesn't make much sense to me and refers to
>>>>> ppc specific stuff in a shared file:
>>>>>
>>>>>       if (is_volatile) {
>>>>> !     if (!is_store) {
>>>>>           insert_mem_bar(Op_MemBarAcquire);
>>>>> !     } else {
>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>           insert_mem_bar(Op_MemBarVolatile);
>>>>> + #endif
>>>>> +     }
>>>>>
>>>>> I don't think the comment is needed.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks for your comments!
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> Sorry for the delay in getting back to this.
>>>>>>
>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>> specifically it is
>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>> Seems
>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>
>>>>>> The changes related to volatile writes in the constructor, as
>>>>>> discussed
>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>> PPC64 porters.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>> this version.
>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lindenmaier, Goetz
>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>> To: David Holmes
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>> not
>>>>>>>> required to pass.
>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>> worked
>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>> it by
>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>> part is
>>>>>>> not that performance relevant.
>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz
>>>>>>>
>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>> emails.
>>>>>>>
>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>> settled.
>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>
>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>> The change is about IRIW.
>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>
>>>>>>> This is the part I still have some question marks over as the
>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>> But I'm
>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>
>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>> stores.
>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>> constructor tests.
>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>> after stores
>>>>>>>>          to pass the volatile constructor tests.
>>>>>>>
>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>> were not
>>>>>>> required to pass.
>>>>>>>
>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>> order
>>>>>>>> instructions are not as find-granular as the
>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>> The only instruction
>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>> therefore the
>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>> proper representation
>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>> it's pointless
>>>>>>>> anyways.
>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>> I'd be happy to add a property
>>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>
>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>> think
>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>> Or also
>>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> TL;DR version:
>>>>>>>>
>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>> constructor-barrier
>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>> *may*
>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>> ensure
>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>> invalid
>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>> need it
>>>>>>>> due to other factors).
>>>>>>>>
>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>> term :)
>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>
>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>> visible to
>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>> architectures
>>>>>>>> are not multiple-copy atomic."
>>>>>>>>
>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>> ARM and
>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>> current issue is what you wrote below:
>>>>>>>>
>>>>>>>>      > The fixes for the constructor issue are only needed because we
>>>>>>>>      > remove the sync instruction from behind stores
>>>>>>>> (parse3.cpp:320)
>>>>>>>>      > and place it before loads.
>>>>>>>>
>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>> after
>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>> same
>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>> load -
>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>> clearer.
>>>>>>>>
>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>> implemented as
>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>> hooks
>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>
>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>> this
>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>
>>>>>>>>> I did not yet add the
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>> or
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>
>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>
>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>> store
>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>> (volatile store in constructor).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>> issue.
>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>> you
>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>> solution,
>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>> issues.
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>> and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>> ARM and
>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>> Work-Stealing for
>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>> taskqueue problem.
>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>
>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>> used 'read'
>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>> above).
>>>>>>>>>
>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>> processors
>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>> Aleksey!)
>>>>>>>>>
>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>
>>>>>>>>>> -- IRIW issue
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>> a few
>>>>>>>>>>> moments thought.
>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>> problem yet,
>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>
>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>> continuous.
>>>>>>>>>
>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?)
>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>> I contributed a
>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>> nice, I admit.
>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>> are evaluated
>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>
>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>> problem
>>>>>>>>>> is that
>>>>>>>>>>         store
>>>>>>>>>>         sync
>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>> only
>>>>>>>>>>         sync
>>>>>>>>>>         load
>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>> pass that test.
>>>>>>>>>
>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>> term and
>>>>>>>>> can't find any reference to it.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>         The JMM is fine. And
>>>>>>>>>>         store
>>>>>>>>>>         MemBarVolatile
>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>> that
>>>>>>>>>> do what is required.
>>>>>>>>>>
>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>
>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>
>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>> initializing
>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>> Shipilev
>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>           LongVolatileTest
>>>>>>>>>>>           AtomicIntegerInitialValueTest
>>>>>>>>>>> will fail.
>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>> volatile field would be
>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>
>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>> volatiles do
>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>> that
>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>> Aleksey
>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>
>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>> heavyweight
>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>> don't
>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>
>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>> account
>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>> different platforms
>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>> An example:
>>>>>>>>>>>          MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>          MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>> this:
>>>>>>>>>>>          MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>          MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>           MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>          MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>> can not implement
>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>
>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>> issue.
>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>> read
>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>
>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>> independent?
>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>
>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>> few
>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>> will
>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>> moment. The
>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>> requirements for
>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>> are not
>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>> store
>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>> of the
>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>> software
>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>> don't have
>>>>>>>>>> that on ppc!)
>>>>>>>>>>
>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>> I will
>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -- Other ports:
>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>> it might
>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>> them).
>>>>>>>>>>>
>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>> can
>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>> way :)
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>
>>>>>>>>>>>         From what I understand what we see here is an attempt to
>>>>>>>>>>> fix an
>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>> IRIW
>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>> doing the
>>>>>>>>>>> load.
>>>>>>>>>>>
>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>> would be
>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>> performance
>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>> that
>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>> this is
>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>> with the
>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>> the
>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>> properties
>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>> on a
>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>> reduce
>>>>>>>>>>> to a no-op.
>>>>>>>>>>>
>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>> under
>>>>>>>>>>> the JMM.
>>>>>>>>>>>
>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>> current
>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>> is set
>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>
>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>
>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>> Java
>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>> explicitly
>>>>>>>>>>> like this.
>>>>>>>>>>>
>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>> there
>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>> defines?
>>>>>>>>>>>>         From what I understand our ppc port is also affected.
>>>>>>>>>>>> David?
>>>>>>>>>>>
>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>
>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>> specific which
>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>
>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>
>>>>>>>>>>>>            if (is_vol) {
>>>>>>>>>>>>              // See comment in do_get_xxx().
>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>              insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>> #else
>>>>>>>>>>>>              if (is_field) {
>>>>>>>>>>>>                // Add MemBarRelease for constructors which write
>>>>>>>>>>>> volatile field
>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>                set_wrote_volatile(true);
>>>>>>>>>>>>              }
>>>>>>>>>>>> #endif
>>>>>>>>>>>>            }
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Example:
>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>           __________    __________    __________    __________
>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>
>>>>>>>>>>>>>            write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>                          read(y)                     read(x)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>> is only
>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>> threads
>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>> fields
>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>> published.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>> seems too
>>>>>>>>>>>>> strong.
>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>

From alejandro.murillo at oracle.com  Fri Jan 17 21:45:58 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 18 Jan 2014 05:45:58 +0000
Subject: hg: hsx/hsx25/hotspot: 24 new changesets
Message-ID: <20140118054650.EA38B62550@hg.openjdk.java.net>

Changeset: f898fdfc08a5
Author:    jeff
Date:      2014-01-13 14:42 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f898fdfc08a5

7129980: Third Party License Readme update for JDK8
Reviewed-by: lana, tbell

! THIRD_PARTY_README

Changeset: b99955ea4b91
Author:    lana
Date:      2014-01-13 22:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b99955ea4b91

Merge


Changeset: 2c3130311ffa
Author:    amurillo
Date:      2014-01-14 11:22 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c3130311ffa

Merge


Changeset: 7ccce1a6fa4d
Author:    coleenp
Date:      2013-09-05 10:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ccce1a6fa4d

8021266: Better life cycle for objects
Summary: Improve life cycle for objects
Reviewed-by: art, hseigel
Contributed-by: gerard.ziemski at oracle.com

! src/share/vm/runtime/os.cpp

Changeset: 2a907fd129cb
Author:    chegar
Date:      2013-09-06 09:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2a907fd129cb

Merge

! src/share/vm/runtime/os.cpp
- test/runtime/7051189/Xchecksig.sh

Changeset: 9b4ce069642e
Author:    chegar
Date:      2013-09-14 20:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9b4ce069642e

Merge

! src/share/vm/classfile/classFileParser.cpp
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/os.cpp

Changeset: 6fa574bfd32a
Author:    chegar
Date:      2013-10-03 19:13 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6fa574bfd32a

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/os.cpp
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: 6795fcebbf42
Author:    chegar
Date:      2013-10-21 14:08 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6795fcebbf42

Merge

! src/share/vm/classfile/classFileParser.cpp
- test/testlibrary/AssertsTest.java
- test/testlibrary/OutputAnalyzerReportingTest.java
- test/testlibrary/OutputAnalyzerTest.java

Changeset: c31f0cbe6d9e
Author:    chegar
Date:      2013-11-03 07:50 +0000
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c31f0cbe6d9e

Merge

- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
- test/compiler/8013496/Test8013496.sh
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/gc/7168848/HumongousAlloc.java

Changeset: 0611ce949aaa
Author:    kizune
Date:      2013-12-03 14:13 +0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0611ce949aaa

Merge

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

Changeset: e254e5940c19
Author:    kizune
Date:      2013-12-05 16:37 +0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e254e5940c19

Merge

! src/share/vm/classfile/classFileParser.cpp
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: 9063bd8808a7
Author:    jrose
Date:      2013-12-05 00:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9063bd8808a7

8029507: Enhance JVM method processing
Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName
Reviewed-by: acorn, vlivanov

! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 1b46c3672650
Author:    kizune
Date:      2013-12-13 22:13 +0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b46c3672650

Merge


Changeset: 8dbd61445631
Author:    asaha
Date:      2013-12-17 15:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8dbd61445631

Merge


Changeset: ddff10b13587
Author:    asaha
Date:      2013-12-20 07:41 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ddff10b13587

Merge


Changeset: a902f789ea1f
Author:    asaha
Date:      2014-01-02 15:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a902f789ea1f

Merge


Changeset: 3b69a859e3f9
Author:    asaha
Date:      2014-01-03 15:58 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3b69a859e3f9

Merge


Changeset: df333ee12bba
Author:    lana
Date:      2014-01-15 10:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df333ee12bba

Merge


Changeset: e2e6ca7e0ea6
Author:    katleman
Date:      2014-01-17 15:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e2e6ca7e0ea6

Added tag jdk8-b124 for changeset df333ee12bba

! .hgtags

Changeset: 16e0c6c84a91
Author:    amurillo
Date:      2014-01-13 16:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/16e0c6c84a91

8031553: new hotspot build - hs25-b67
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 12ad8db39f76
Author:    roland
Date:      2014-01-14 09:44 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/12ad8db39f76

8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a
Summary: C1 generates code to encode compressed oop into tmp register before runtime call for patching where GC may happen
Reviewed-by: iveresov, twisti, kvn
Contributed-by: mgerdin <mikael.gerdin at oracle.com>

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 8b81451dc7f7
Author:    twisti
Date:      2014-01-16 16:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b81451dc7f7

8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp

Changeset: 3585183c191a
Author:    amurillo
Date:      2014-01-17 20:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3585183c191a

Merge


Changeset: 5df2666e4573
Author:    amurillo
Date:      2014-01-17 20:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5df2666e4573

Added tag hs25-b67 for changeset 3585183c191a

! .hgtags


From alejandro.murillo at oracle.com  Fri Jan 17 22:51:49 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 18 Jan 2014 06:51:49 +0000
Subject: hg: hsx/hotspot-main/hotspot: 22 new changesets
Message-ID: <20140118065236.C1ACB62560@hg.openjdk.java.net>

Changeset: f898fdfc08a5
Author:    jeff
Date:      2014-01-13 14:42 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f898fdfc08a5

7129980: Third Party License Readme update for JDK8
Reviewed-by: lana, tbell

! THIRD_PARTY_README

Changeset: b99955ea4b91
Author:    lana
Date:      2014-01-13 22:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b99955ea4b91

Merge


Changeset: 2c3130311ffa
Author:    amurillo
Date:      2014-01-14 11:22 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c3130311ffa

Merge


Changeset: 7ccce1a6fa4d
Author:    coleenp
Date:      2013-09-05 10:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ccce1a6fa4d

8021266: Better life cycle for objects
Summary: Improve life cycle for objects
Reviewed-by: art, hseigel
Contributed-by: gerard.ziemski at oracle.com

! src/share/vm/runtime/os.cpp

Changeset: 2a907fd129cb
Author:    chegar
Date:      2013-09-06 09:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2a907fd129cb

Merge

! src/share/vm/runtime/os.cpp
- test/runtime/7051189/Xchecksig.sh

Changeset: 9b4ce069642e
Author:    chegar
Date:      2013-09-14 20:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9b4ce069642e

Merge

! src/share/vm/classfile/classFileParser.cpp
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/os.cpp

Changeset: 6fa574bfd32a
Author:    chegar
Date:      2013-10-03 19:13 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6fa574bfd32a

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/os.cpp
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: 6795fcebbf42
Author:    chegar
Date:      2013-10-21 14:08 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6795fcebbf42

Merge

! src/share/vm/classfile/classFileParser.cpp
- test/testlibrary/AssertsTest.java
- test/testlibrary/OutputAnalyzerReportingTest.java
- test/testlibrary/OutputAnalyzerTest.java

Changeset: c31f0cbe6d9e
Author:    chegar
Date:      2013-11-03 07:50 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c31f0cbe6d9e

Merge

- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
- test/compiler/8013496/Test8013496.sh
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/gc/7168848/HumongousAlloc.java

Changeset: 0611ce949aaa
Author:    kizune
Date:      2013-12-03 14:13 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0611ce949aaa

Merge

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

Changeset: e254e5940c19
Author:    kizune
Date:      2013-12-05 16:37 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e254e5940c19

Merge

! src/share/vm/classfile/classFileParser.cpp
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: 9063bd8808a7
Author:    jrose
Date:      2013-12-05 00:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9063bd8808a7

8029507: Enhance JVM method processing
Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName
Reviewed-by: acorn, vlivanov

! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 1b46c3672650
Author:    kizune
Date:      2013-12-13 22:13 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b46c3672650

Merge


Changeset: 8dbd61445631
Author:    asaha
Date:      2013-12-17 15:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8dbd61445631

Merge


Changeset: ddff10b13587
Author:    asaha
Date:      2013-12-20 07:41 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ddff10b13587

Merge


Changeset: a902f789ea1f
Author:    asaha
Date:      2014-01-02 15:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a902f789ea1f

Merge


Changeset: 3b69a859e3f9
Author:    asaha
Date:      2014-01-03 15:58 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b69a859e3f9

Merge


Changeset: df333ee12bba
Author:    lana
Date:      2014-01-15 10:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df333ee12bba

Merge


Changeset: e2e6ca7e0ea6
Author:    katleman
Date:      2014-01-17 15:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e2e6ca7e0ea6

Added tag jdk8-b124 for changeset df333ee12bba

! .hgtags

Changeset: 3585183c191a
Author:    amurillo
Date:      2014-01-17 20:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3585183c191a

Merge


Changeset: 5df2666e4573
Author:    amurillo
Date:      2014-01-17 20:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5df2666e4573

Added tag hs25-b67 for changeset 3585183c191a

! .hgtags

Changeset: c2106608358b
Author:    amurillo
Date:      2014-01-17 20:30 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c2106608358b

8032015: new hotspot build - hs25-b68
Reviewed-by: jcoomes

! make/hotspot_version


From goetz.lindenmaier at sap.com  Sat Jan 18 02:36:02 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 18 Jan 2014 10:36:02 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52D9D35F.2050501@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52D9D35F.2050501@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D566@DEWDFEMB12A.global.corp.sap>

Hi,

I updated the comments in the webrev accordingly.
http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/

Best regards,
  Goetz.


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Saturday, January 18, 2014 2:06 AM
To: Lindenmaier, Goetz; David Holmes
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Goetz,

I asked to remove both comments in parse.hpp, comments in parse1.cpp and 
parse3.cpp is enough. It should be similar to _wrote_final:

    bool          _wrote_volatile;   // Did we write a final field?


I think the next comment in parse3.cpp should be modified:

+    // But remember we wrote a volatile field so that a barrier can be 
issued
+    // in constructors. See do_exits() in parse1.cpp.

// Remember we wrote a volatile field.
// For not multiple copy atomic cpu (ppc64) a barrier should be issued
// in constructors which have such stores. See do_exits() in parse1.cpp.

Thanks,
Vladimir

On 1/17/14 12:39 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I tried to come up with a webrev that implements the change as proposed in
> your mails:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>
> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
> support_IRIW_for_not_multiple_copy_atomic_cpu.
>
> I left the definition and handling of _wrote_volatile in the code, without
> any protection.
> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
> and put it on one line.
>
> I removed the comment in library_call.cpp.
> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
> from the comments as it's PPC specific.
>
> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
> issues in C1 if nobody did it by then.
>
> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>
> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 16. Januar 2014 10:05
> To: Vladimir Kozlov
> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>> On 1/16/14 12:34 AM, David Holmes wrote:
>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>> want to keep it this way, it could be useful to have such info on other
>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>> parse.hpp.
>>>>
>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>> which could be checked in all places instead of #ifdef:
>>>
>>> I asked for the ifdef some time back as I find it much preferable to
>>> have this as a build-time construct rather than a
>>> runtime one. I don't want to have to pay anything for this if we don't
>>> use it.
>>
>> Any decent C++ compiler will optimize expressions with such constants
>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>
> If you insist then we may as well do it all the same way. Better to be
> consistent.
>
> My apologies Goetz for wasting your time going back and forth on this.
>
> That aside I have a further concern with this IRIW support - it is
> incomplete as there is no C1 support, as PPC64 isn't using client. If
> this is going on then we (which probably means the Oracle 'we') need to
> add the missing C1 code.
>
> David
> -----
>
>> Vladimir
>>
>>>
>>> David
>>>
>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>> #else
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>> #endif
>>>>
>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>
>>>> and then:
>>>>
>>>>    #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>      oop p = JNIHandles::resolve(obj); \
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>> OrderAccess::fence(); \
>>>>      volatile type_name v = OrderAccess::load_acquire((volatile
>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>
>>>> And:
>>>>
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>> field->is_volatile()) {
>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>> +  }
>>>>
>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>
>>>> The code in parse1.cpp could be put on one line:
>>>>
>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>> method()->is_initializer()) )) {
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> I updated the webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>
>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>     reflect the new flagging.  Also I mention that we support the
>>>>>>     volatile constructor issue, but that it's not standard.
>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>     I also think it's better to separate these this way.
>>>>>
>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>> please.
>>>>>
>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>> comment doesn't make much sense to me and refers to
>>>>> ppc specific stuff in a shared file:
>>>>>
>>>>>       if (is_volatile) {
>>>>> !     if (!is_store) {
>>>>>           insert_mem_bar(Op_MemBarAcquire);
>>>>> !     } else {
>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>           insert_mem_bar(Op_MemBarVolatile);
>>>>> + #endif
>>>>> +     }
>>>>>
>>>>> I don't think the comment is needed.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks for your comments!
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> Sorry for the delay in getting back to this.
>>>>>>
>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>> specifically it is
>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>> Seems
>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>
>>>>>> The changes related to volatile writes in the constructor, as
>>>>>> discussed
>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>> PPC64 porters.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>> this version.
>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lindenmaier, Goetz
>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>> To: David Holmes
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>> not
>>>>>>>> required to pass.
>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>> worked
>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>> it by
>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>> part is
>>>>>>> not that performance relevant.
>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz
>>>>>>>
>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>> emails.
>>>>>>>
>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>> settled.
>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>
>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>> The change is about IRIW.
>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>
>>>>>>> This is the part I still have some question marks over as the
>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>> But I'm
>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>
>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>> stores.
>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>> constructor tests.
>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>> after stores
>>>>>>>>          to pass the volatile constructor tests.
>>>>>>>
>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>> were not
>>>>>>> required to pass.
>>>>>>>
>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>> order
>>>>>>>> instructions are not as find-granular as the
>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>> The only instruction
>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>> therefore the
>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>> proper representation
>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>> it's pointless
>>>>>>>> anyways.
>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>> I'd be happy to add a property
>>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>
>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>> think
>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>> Or also
>>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> TL;DR version:
>>>>>>>>
>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>> constructor-barrier
>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>> *may*
>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>> ensure
>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>> invalid
>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>> need it
>>>>>>>> due to other factors).
>>>>>>>>
>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>> term :)
>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>
>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>> visible to
>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>> architectures
>>>>>>>> are not multiple-copy atomic."
>>>>>>>>
>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>> ARM and
>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>> current issue is what you wrote below:
>>>>>>>>
>>>>>>>>      > The fixes for the constructor issue are only needed because we
>>>>>>>>      > remove the sync instruction from behind stores
>>>>>>>> (parse3.cpp:320)
>>>>>>>>      > and place it before loads.
>>>>>>>>
>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>> after
>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>> same
>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>> load -
>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>> clearer.
>>>>>>>>
>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>> implemented as
>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>> hooks
>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>
>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>> this
>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>
>>>>>>>>> I did not yet add the
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>> or
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>
>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>
>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>> store
>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>> (volatile store in constructor).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>> issue.
>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>> you
>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>> solution,
>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>> issues.
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>> and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>> ARM and
>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>> Work-Stealing for
>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>> taskqueue problem.
>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>
>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>> used 'read'
>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>> above).
>>>>>>>>>
>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>> processors
>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>> Aleksey!)
>>>>>>>>>
>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>
>>>>>>>>>> -- IRIW issue
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>> a few
>>>>>>>>>>> moments thought.
>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>> problem yet,
>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>
>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>> continuous.
>>>>>>>>>
>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?)
>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>> I contributed a
>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>> nice, I admit.
>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>> are evaluated
>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>
>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>> problem
>>>>>>>>>> is that
>>>>>>>>>>         store
>>>>>>>>>>         sync
>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>> only
>>>>>>>>>>         sync
>>>>>>>>>>         load
>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>> pass that test.
>>>>>>>>>
>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>> term and
>>>>>>>>> can't find any reference to it.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>         The JMM is fine. And
>>>>>>>>>>         store
>>>>>>>>>>         MemBarVolatile
>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>> that
>>>>>>>>>> do what is required.
>>>>>>>>>>
>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>
>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>
>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>> initializing
>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>> Shipilev
>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>           LongVolatileTest
>>>>>>>>>>>           AtomicIntegerInitialValueTest
>>>>>>>>>>> will fail.
>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>> volatile field would be
>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>
>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>> volatiles do
>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>> that
>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>> Aleksey
>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>
>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>> heavyweight
>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>> don't
>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>
>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>> account
>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>> different platforms
>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>> An example:
>>>>>>>>>>>          MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>          MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>> this:
>>>>>>>>>>>          MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>          MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>           MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>          MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>> can not implement
>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>
>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>> issue.
>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>> read
>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>
>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>> independent?
>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>
>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>> few
>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>> will
>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>> moment. The
>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>> requirements for
>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>> are not
>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>> store
>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>> of the
>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>> software
>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>> don't have
>>>>>>>>>> that on ppc!)
>>>>>>>>>>
>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>> I will
>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -- Other ports:
>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>> it might
>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>> them).
>>>>>>>>>>>
>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>> can
>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>> way :)
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>
>>>>>>>>>>>         From what I understand what we see here is an attempt to
>>>>>>>>>>> fix an
>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>> IRIW
>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>> doing the
>>>>>>>>>>> load.
>>>>>>>>>>>
>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>> would be
>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>> performance
>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>> that
>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>> this is
>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>> with the
>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>> the
>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>> properties
>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>> on a
>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>> reduce
>>>>>>>>>>> to a no-op.
>>>>>>>>>>>
>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>> under
>>>>>>>>>>> the JMM.
>>>>>>>>>>>
>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>> current
>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>> is set
>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>
>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>
>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>> Java
>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>> explicitly
>>>>>>>>>>> like this.
>>>>>>>>>>>
>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>> there
>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>> defines?
>>>>>>>>>>>>         From what I understand our ppc port is also affected.
>>>>>>>>>>>> David?
>>>>>>>>>>>
>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>
>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>> specific which
>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>
>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>
>>>>>>>>>>>>            if (is_vol) {
>>>>>>>>>>>>              // See comment in do_get_xxx().
>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>              insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>> #else
>>>>>>>>>>>>              if (is_field) {
>>>>>>>>>>>>                // Add MemBarRelease for constructors which write
>>>>>>>>>>>> volatile field
>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>                set_wrote_volatile(true);
>>>>>>>>>>>>              }
>>>>>>>>>>>> #endif
>>>>>>>>>>>>            }
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Example:
>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>           __________    __________    __________    __________
>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>
>>>>>>>>>>>>>            write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>                          read(y)                     read(x)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>> is only
>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>> threads
>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>> fields
>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>> published.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>> seems too
>>>>>>>>>>>>> strong.
>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>

From vladimir.kozlov at oracle.com  Sat Jan 18 09:36:04 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sat, 18 Jan 2014 09:36:04 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8D566@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52D9D35F.2050501@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D566@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DABB84.1090400@oracle.com>

Good.

Thanks,
Vladimir

On 1/18/14 2:36 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I updated the comments in the webrev accordingly.
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>
> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Saturday, January 18, 2014 2:06 AM
> To: Lindenmaier, Goetz; David Holmes
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Goetz,
>
> I asked to remove both comments in parse.hpp, comments in parse1.cpp and
> parse3.cpp is enough. It should be similar to _wrote_final:
>
>      bool          _wrote_volatile;   // Did we write a final field?
>
>
> I think the next comment in parse3.cpp should be modified:
>
> +    // But remember we wrote a volatile field so that a barrier can be
> issued
> +    // in constructors. See do_exits() in parse1.cpp.
>
> // Remember we wrote a volatile field.
> // For not multiple copy atomic cpu (ppc64) a barrier should be issued
> // in constructors which have such stores. See do_exits() in parse1.cpp.
>
> Thanks,
> Vladimir
>
> On 1/17/14 12:39 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I tried to come up with a webrev that implements the change as proposed in
>> your mails:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>
>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>
>> I left the definition and handling of _wrote_volatile in the code, without
>> any protection.
>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>> and put it on one line.
>>
>> I removed the comment in library_call.cpp.
>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>> from the comments as it's PPC specific.
>>
>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>> issues in C1 if nobody did it by then.
>>
>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 16. Januar 2014 10:05
>> To: Vladimir Kozlov
>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>> want to keep it this way, it could be useful to have such info on other
>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>> parse.hpp.
>>>>>
>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>> which could be checked in all places instead of #ifdef:
>>>>
>>>> I asked for the ifdef some time back as I find it much preferable to
>>>> have this as a build-time construct rather than a
>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>> use it.
>>>
>>> Any decent C++ compiler will optimize expressions with such constants
>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>
>> If you insist then we may as well do it all the same way. Better to be
>> consistent.
>>
>> My apologies Goetz for wasting your time going back and forth on this.
>>
>> That aside I have a further concern with this IRIW support - it is
>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>> this is going on then we (which probably means the Oracle 'we') need to
>> add the missing C1 code.
>>
>> David
>> -----
>>
>>> Vladimir
>>>
>>>>
>>>> David
>>>>
>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>> #else
>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>> #endif
>>>>>
>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>
>>>>> and then:
>>>>>
>>>>>     #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>       oop p = JNIHandles::resolve(obj); \
>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>> OrderAccess::fence(); \
>>>>>       volatile type_name v = OrderAccess::load_acquire((volatile
>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>
>>>>> And:
>>>>>
>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>> field->is_volatile()) {
>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>> +  }
>>>>>
>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>
>>>>> The code in parse1.cpp could be put on one line:
>>>>>
>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>> method()->is_initializer()) )) {
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I updated the webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>      reflect the new flagging.  Also I mention that we support the
>>>>>>>      volatile constructor issue, but that it's not standard.
>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>      I also think it's better to separate these this way.
>>>>>>
>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>> please.
>>>>>>
>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>> comment doesn't make much sense to me and refers to
>>>>>> ppc specific stuff in a shared file:
>>>>>>
>>>>>>        if (is_volatile) {
>>>>>> !     if (!is_store) {
>>>>>>            insert_mem_bar(Op_MemBarAcquire);
>>>>>> !     } else {
>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>            insert_mem_bar(Op_MemBarVolatile);
>>>>>> + #endif
>>>>>> +     }
>>>>>>
>>>>>> I don't think the comment is needed.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Thanks for your comments!
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi Goetz,
>>>>>>>
>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>
>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>> specifically it is
>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>> Seems
>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>
>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>> discussed
>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>> PPC64 porters.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>> this version.
>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>> To: David Holmes
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>> not
>>>>>>>>> required to pass.
>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>> worked
>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>> it by
>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>> part is
>>>>>>>> not that performance relevant.
>>>>>>>>
>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>> think
>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz
>>>>>>>>
>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>> emails.
>>>>>>>>
>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>> settled.
>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>
>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>> The change is about IRIW.
>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>
>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>> But I'm
>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>
>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>> stores.
>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>> constructor tests.
>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>> after stores
>>>>>>>>>           to pass the volatile constructor tests.
>>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>> were not
>>>>>>>> required to pass.
>>>>>>>>
>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>> order
>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>> The only instruction
>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>> therefore the
>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>> proper representation
>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>> it's pointless
>>>>>>>>> anyways.
>>>>>>>>>
>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>> I'd be happy to add a property
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>> Or also
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> TL;DR version:
>>>>>>>>>
>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>> constructor-barrier
>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>> *may*
>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>> ensure
>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>> invalid
>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>> need it
>>>>>>>>> due to other factors).
>>>>>>>>>
>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>> term :)
>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>
>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>> visible to
>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>> architectures
>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>
>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>> ARM and
>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>
>>>>>>>>>       > The fixes for the constructor issue are only needed because we
>>>>>>>>>       > remove the sync instruction from behind stores
>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>       > and place it before loads.
>>>>>>>>>
>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>> after
>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>> same
>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>> load -
>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>> clearer.
>>>>>>>>>
>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>> implemented as
>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>> hooks
>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>> this
>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>
>>>>>>>>>> I did not yet add the
>>>>>>>>>>          OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>          VM_Version::needs_support_iriw_ordering()
>>>>>>>>>> or
>>>>>>>>>>         OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>
>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>
>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>> store
>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @David
>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>> continuous.
>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>> issue.
>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>> you
>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>> solution,
>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>> issues.
>>>>>>>>>>
>>>>>>>>>> @David
>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>> and
>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>> ARM and
>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>> Work-Stealing for
>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>> taskqueue problem.
>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>
>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>> used 'read'
>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>> above).
>>>>>>>>>>
>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>> processors
>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>> Aleksey!)
>>>>>>>>>>
>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>
>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>> a few
>>>>>>>>>>>> moments thought.
>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>> problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>>>
>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>> different?)
>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>> I contributed a
>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>> nice, I admit.
>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>> are evaluated
>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>
>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>> problem
>>>>>>>>>>> is that
>>>>>>>>>>>          store
>>>>>>>>>>>          sync
>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>> only
>>>>>>>>>>>          sync
>>>>>>>>>>>          load
>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>> pass that test.
>>>>>>>>>>
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>> term and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>          The JMM is fine. And
>>>>>>>>>>>          store
>>>>>>>>>>>          MemBarVolatile
>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>> that
>>>>>>>>>>> do what is required.
>>>>>>>>>>>
>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>
>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>> initializing
>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>> Shipilev
>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>            LongVolatileTest
>>>>>>>>>>>>            AtomicIntegerInitialValueTest
>>>>>>>>>>>> will fail.
>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>
>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>> volatiles do
>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>> that
>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>> Aleksey
>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>
>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>> don't
>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>
>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>> account
>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>> different platforms
>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>> An example:
>>>>>>>>>>>>           MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>           MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>> this:
>>>>>>>>>>>>           MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>           MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>            MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>           MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>> can not implement
>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>
>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>> issue.
>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>> read
>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>
>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>> independent?
>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>> few
>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>> will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>> moment. The
>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>> requirements for
>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>> are not
>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>> store
>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>> of the
>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>> software
>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>> don't have
>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>
>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>> I will
>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>> it might
>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>> them).
>>>>>>>>>>>>
>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>> can
>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>> way :)
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>
>>>>>>>>>>>>          From what I understand what we see here is an attempt to
>>>>>>>>>>>> fix an
>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>> IRIW
>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>> doing the
>>>>>>>>>>>> load.
>>>>>>>>>>>>
>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>> would be
>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>> performance
>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>> that
>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>> this is
>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>> with the
>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>> the
>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>> properties
>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>> on a
>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>> reduce
>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>
>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>> under
>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>
>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>> current
>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>> is set
>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>
>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>
>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>> Java
>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>> explicitly
>>>>>>>>>>>> like this.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>> there
>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>> defines?
>>>>>>>>>>>>>          From what I understand our ppc port is also affected.
>>>>>>>>>>>>> David?
>>>>>>>>>>>>
>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>> specific which
>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>             if (is_vol) {
>>>>>>>>>>>>>               // See comment in do_get_xxx().
>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>> #else
>>>>>>>>>>>>>               if (is_field) {
>>>>>>>>>>>>>                 // Add MemBarRelease for constructors which write
>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>                 set_wrote_volatile(true);
>>>>>>>>>>>>>               }
>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>             }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>            __________    __________    __________    __________
>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>                           read(y)                     read(x)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>

From david.holmes at oracle.com  Sun Jan 19 18:44:57 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 Jan 2014 12:44:57 +1000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>	<52B3A3AF.9050609@oracle.com>
	<52D76E6F.8070504@oracle.com>	<52D821CB.6020207@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DC8DA9.2010106@oracle.com>

On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I had a look at the first part of this issue: Whether StoreStore
> is necessary in the interpreter.  Let's for now assume the serialization
> page mechanism works on PPC.
>
> In the state transition leaving the VM state, which is executed in the
> destructor, ThreadStateTransition::transition() is called, which executes
>        if (UseMembar) {
>          OrderAccess::fence();
>        } else {
>          os::write_memory_serialize_page(thread);
>        }
>
> os:: write_memory_serialize_page() can not be considered a proper
> MemBar, as it only serializes if another thread poisoned the page.
> Thus it does not qualify to order the initialization and the publishing
> of the object.
>
> You are right, if UseMembar is true, the StoreStore in the interpreter
> is superfluous.  We could guard the StoreStores in the interpreter by
> !UseMembar.

My understanding, from our existing non-TSO system ports, is that the 
present assumption is that either:

a) you have a TSO system, in which case you are probably using the 
serialization page, but you don't need any barrier to enforce ordering 
anyway; or

b) you don't have a TSO system, you are using UseMembar==true and so you 
get a full fence inserted that enforces the ordering anyway.

So the ordering requirements are satisfied by piggy-backing on the 
UseMembar setting that comes from the thread state transition code, 
which forms part of the "runtime entry" code. That's not to say that you 
will necessarily find this applied consistently in all places where it 
might be applied - nor will you necessarily find that this is common 
knowledge amongst VM engineers.

Technically the storeStore barriers could be conditional on !UseMembar 
but that is redundant in the current usage.

> But then again, one is to order the publishing of the thread states,
> the other to enforce some Java semantics.  I don't know whether everybody
> who changes in one place is aware of both issues.  But if you want to,
> I'll add a !UseMembar in the interpreter.

Here are my preferred options in order:

1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - 
rely on the piggy-backing effect.

2. Conditionalize the new storeStore barriers on !UseMembar. This 
unfortunately penalizes all platforms with a runtime check.

3. Add the storeStores unconditionally. This penalizes platforms that 
set UseMembar==true as we will now get two fences at runtime.

I know we're talking about the interpreter here so performance is not 
exactly critical, but still ...

> Maybe it would be a good idea
> to document the double use in interfaceSupport.cpp, too.  And maybe
> add an assertion of some kind.

interfaceSupport doesn't know that other code piggy-backs on the fact 
state-transitions have full fences when UseMembar is true. If it is 
documented anywhere it should be in the interpreter (and any other 
places that makes the same assumption) - something like:

// On non-TSO systems there can be additional ordering constraints
// between Java-level actions (such as allocation and constructor
// invocation) that in principle need explicit memory barriers.
// However, on many non-TSO systems the thread-state transition logic
// in the IRT_ENTRY code will insert a full fence due to the use of
// UseMembar==true, which provides the necessary ordering guarantees.

>
> We're digging into the other issue currenty, whether the serialization page
> works on ppc.  We understand your concerns and have no simple answer to
> it right now.  At least, in our VM and in the port there are no known problems
> with the state transitions.

Even if the memory serialization page does not work, in a guaranteed 
sense, on PPC-AIX, it is extremely unlikely that testing would expose 
this. Also note that the memory serialization page behaviour is more a 
function of the OS - so it may be that AIX is different to linux in that 
regard.

Cheers,
David
-----

> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Donnerstag, 16. Januar 2014 19:16
> To: David Holmes; Lindenmaier, Goetz
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>
> Changes are in C++ Interpreter so it does not affect Oracle VM.
> But David has point here. I would like to hear the explanation too.
>
> BTW, I see that for ppc64:
>
> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>
> as result write_memory_serialize_page() is used in
> ThreadStateTransition::transition().
>
> Is it not enough on PPC64?
>
> Thanks,
> Vladimir
>
> On 1/15/14 9:30 PM, David Holmes wrote:
>> Can I get some response on this please - specifically the redundancy wrt
>> IRT_ENTRY actions.
>>
>> Thanks,
>> David
>>
>> On 20/12/2013 11:55 AM, David Holmes wrote:
>>> Still catching up ...
>>>
>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> this change adds StoreStore barriers after object initialization and
>>>> after constructor calls in the C++ interpreter.  This assures no
>>>> uninitialized
>>>> objects or final fields are visible.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>>
>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>>> thread state transitions that already include a full "fence" so the
>>> storestore barriers are redundant in those cases.
>>>
>>> The fastpath _new storestore seems okay.
>>>
>>> I don't know how handle_return gets used to know if it is reasonable or
>>> not.
>>>
>>> I was trying, unsuccessfully, to examine the same code in the
>>> templateInterpreter to see how it handles these cases as it naturally
>>> has the same object-initialization-safety requirements (though these can
>>> be handled in a number of different ways other than an unconditional
>>> storestore barrier at the end of the initialization and construction
>>> phases.
>>>
>>> David
>>> -----
>>>
>>>> Please review and test this change.
>>>>
>>>> Best regards,
>>>>     Goetz.
>>>>

From igor.ignatyev at oracle.com  Mon Jan 20 04:27:50 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Jan 2014 16:27:50 +0400
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
Message-ID: <52DD1646.8030505@oracle.com>

Hi all,

Please review patch:

Problem:
tests 'compiler/tiered/NonTieredLevelsTest.java' and 
'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group

Fix:
tests are added into 'need_compact3'

webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8028482
-- 
Igor

From erik.joelsson at oracle.com  Mon Jan 20 04:54:34 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 20 Jan 2014 13:54:34 +0100
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52D98C9E.8070906@oracle.com>
References: <52D98C9E.8070906@oracle.com>
Message-ID: <52DD1C8A.4020502@oracle.com>

I suggested the change back then and even though I had to think for a 
while to figure out what it did, it still looks correct.

As for pushing, as a jdk9 committer, it is my understanding that you are 
allowed to push it yourself to Hotspot, as long as you use Jprt and push 
to the correct group repo.

/Erik

On 2014-01-17 21:03, Henry Jen wrote:
> Hi,
>
> This is a follow up on an issue first reported on Nov. 2, the fix had 
> been discussed at that time[1] and works for me.
>
> The issue is that the sed command in adjust-mflags.sh trying to 
> isolate -j switch failed to deal with new MFLAGS format spitted out by 
> gmake 4, where the -I<path> without a space, and so if the path 
> contains 'j', the script is confused.
>
> Here is a webrev for JDK9,
> http://cr.openjdk.java.net/~henryjen/jdk9/8028407/0/
>
> Would like to have a sponsor review and push the change, I am tired of 
> patching this. :)
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011692.html
>
> Cheers,
> Henry


From goetz.lindenmaier at sap.com  Mon Jan 20 05:41:26 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Jan 2014 13:41:26 +0000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <52DC8DA9.2010106@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>
	<52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com>
	<52D821CB.6020207@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>
	<52DC8DA9.2010106@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap>

Hi David, 

I understand your arguments and basically agree with them.
If the serialization page does not work on PPC, your solution 
1) is best.

But I'm not sure why there should be a link between TSO and whether
the serialization page trick works.  Second depends, as you say, 
on the OS implementation.
I would assume that the write to the serialization page causes 
the OS to generate a new TLB entry or the like, involving the 
use of a ptwsync instruction which would be fine.  But we are 
investigating this.

We are also experimenting with a small regression test to find
out whether the  serialization page ever fails.

Best regards,
  Goetz.





-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Montag, 20. Januar 2014 03:45
To: Lindenmaier, Goetz; Vladimir Kozlov
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization

On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I had a look at the first part of this issue: Whether StoreStore
> is necessary in the interpreter.  Let's for now assume the serialization
> page mechanism works on PPC.
>
> In the state transition leaving the VM state, which is executed in the
> destructor, ThreadStateTransition::transition() is called, which executes
>        if (UseMembar) {
>          OrderAccess::fence();
>        } else {
>          os::write_memory_serialize_page(thread);
>        }
>
> os:: write_memory_serialize_page() can not be considered a proper
> MemBar, as it only serializes if another thread poisoned the page.
> Thus it does not qualify to order the initialization and the publishing
> of the object.
>
> You are right, if UseMembar is true, the StoreStore in the interpreter
> is superfluous.  We could guard the StoreStores in the interpreter by
> !UseMembar.

My understanding, from our existing non-TSO system ports, is that the 
present assumption is that either:

a) you have a TSO system, in which case you are probably using the 
serialization page, but you don't need any barrier to enforce ordering 
anyway; or

b) you don't have a TSO system, you are using UseMembar==true and so you 
get a full fence inserted that enforces the ordering anyway.

So the ordering requirements are satisfied by piggy-backing on the 
UseMembar setting that comes from the thread state transition code, 
which forms part of the "runtime entry" code. That's not to say that you 
will necessarily find this applied consistently in all places where it 
might be applied - nor will you necessarily find that this is common 
knowledge amongst VM engineers.

Technically the storeStore barriers could be conditional on !UseMembar 
but that is redundant in the current usage.

> But then again, one is to order the publishing of the thread states,
> the other to enforce some Java semantics.  I don't know whether everybody
> who changes in one place is aware of both issues.  But if you want to,
> I'll add a !UseMembar in the interpreter.

Here are my preferred options in order:

1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - 
rely on the piggy-backing effect.

2. Conditionalize the new storeStore barriers on !UseMembar. This 
unfortunately penalizes all platforms with a runtime check.

3. Add the storeStores unconditionally. This penalizes platforms that 
set UseMembar==true as we will now get two fences at runtime.

I know we're talking about the interpreter here so performance is not 
exactly critical, but still ...

> Maybe it would be a good idea
> to document the double use in interfaceSupport.cpp, too.  And maybe
> add an assertion of some kind.

interfaceSupport doesn't know that other code piggy-backs on the fact 
state-transitions have full fences when UseMembar is true. If it is 
documented anywhere it should be in the interpreter (and any other 
places that makes the same assumption) - something like:

// On non-TSO systems there can be additional ordering constraints
// between Java-level actions (such as allocation and constructor
// invocation) that in principle need explicit memory barriers.
// However, on many non-TSO systems the thread-state transition logic
// in the IRT_ENTRY code will insert a full fence due to the use of
// UseMembar==true, which provides the necessary ordering guarantees.

>
> We're digging into the other issue currenty, whether the serialization page
> works on ppc.  We understand your concerns and have no simple answer to
> it right now.  At least, in our VM and in the port there are no known problems
> with the state transitions.

Even if the memory serialization page does not work, in a guaranteed 
sense, on PPC-AIX, it is extremely unlikely that testing would expose 
this. Also note that the memory serialization page behaviour is more a 
function of the OS - so it may be that AIX is different to linux in that 
regard.

Cheers,
David
-----

> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Donnerstag, 16. Januar 2014 19:16
> To: David Holmes; Lindenmaier, Goetz
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>
> Changes are in C++ Interpreter so it does not affect Oracle VM.
> But David has point here. I would like to hear the explanation too.
>
> BTW, I see that for ppc64:
>
> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>
> as result write_memory_serialize_page() is used in
> ThreadStateTransition::transition().
>
> Is it not enough on PPC64?
>
> Thanks,
> Vladimir
>
> On 1/15/14 9:30 PM, David Holmes wrote:
>> Can I get some response on this please - specifically the redundancy wrt
>> IRT_ENTRY actions.
>>
>> Thanks,
>> David
>>
>> On 20/12/2013 11:55 AM, David Holmes wrote:
>>> Still catching up ...
>>>
>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> this change adds StoreStore barriers after object initialization and
>>>> after constructor calls in the C++ interpreter.  This assures no
>>>> uninitialized
>>>> objects or final fields are visible.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>>
>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>>> thread state transitions that already include a full "fence" so the
>>> storestore barriers are redundant in those cases.
>>>
>>> The fastpath _new storestore seems okay.
>>>
>>> I don't know how handle_return gets used to know if it is reasonable or
>>> not.
>>>
>>> I was trying, unsuccessfully, to examine the same code in the
>>> templateInterpreter to see how it handles these cases as it naturally
>>> has the same object-initialization-safety requirements (though these can
>>> be handled in a number of different ways other than an unconditional
>>> storestore barrier at the end of the initialization and construction
>>> phases.
>>>
>>> David
>>> -----
>>>
>>>> Please review and test this change.
>>>>
>>>> Best regards,
>>>>     Goetz.
>>>>

From roland.westrelin at oracle.com  Mon Jan 20 08:21:59 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 20 Jan 2014 17:21:59 +0100
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <52DD1646.8030505@oracle.com>
References: <52DD1646.8030505@oracle.com>
Message-ID: <DC434523-81B2-43B6-B113-5A683C2C8585@oracle.com>

> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/

That looks good to me.

Roland.


From staffan.larsen at oracle.com  Mon Jan 20 10:02:15 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 20 Jan 2014 19:02:15 +0100
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <DC434523-81B2-43B6-B113-5A683C2C8585@oracle.com>
References: <52DD1646.8030505@oracle.com>
	<DC434523-81B2-43B6-B113-5A683C2C8585@oracle.com>
Message-ID: <7584D6FF-25B8-40BD-AFF6-593BFBD341AB@oracle.com>

Looks good!

Thanks,
/Staffan

On 20 jan 2014, at 17:21, Roland Westrelin <roland.westrelin at oracle.com> wrote:

>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
> 
> That looks good to me.
> 
> Roland.
> 


From neugens at redhat.com  Mon Jan 20 10:21:30 2014
From: neugens at redhat.com (Mario Torre)
Date: Mon, 20 Jan 2014 19:21:30 +0100
Subject: Hostpot fails to compile (RHEL 6.5)
Message-ID: <1390242091.3882.7.camel@galactica.localdomain>

Hi all,

While trying to compile OpenJDK8 (latest hg), I found a couple of errors
in hotspot:

/home/neugens/work_space/redhat/jdk8_orig/hotspot/src/share/vm/services/classLoadingService.cpp: In static member function ?static void ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)?:
/home/neugens/work_space/redhat/jdk8_orig/hotspot/src/share/vm/services/classLoadingService.cpp:165: error: cannot reload integer constant operand in ?asm?
/home/neugens/work_space/redhat/jdk8_orig/hotspot/src/share/vm/services/classLoadingService.cpp:165: error: cannot reload integer constant operand in ?asm?
gmake[6]: *** [classLoadingService.o] Error 1

I believe this depends on some hardening of gcc rules, but it seems
quite recent.

My gcc version is:

[neugens at galactica jdk8]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

I have a quick patch for this but I don't know if a better fix is under
development. In any case, here's the link:

http://cr.openjdk.java.net/~neugens/hostpot_fix_2014-01-20/webrev.00/

Cheers,
Mario



From david.holmes at oracle.com  Mon Jan 20 18:49:01 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jan 2014 12:49:01 +1000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>	<52B3A3AF.9050609@oracle.com>
	<52D76E6F.8070504@oracle.com>	<52D821CB.6020207@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>
	<52DC8DA9.2010106@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DDE01D.1060605@oracle.com>

On 20/01/2014 11:41 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> I understand your arguments and basically agree with them.
> If the serialization page does not work on PPC, your solution
> 1) is best.
>
> But I'm not sure why there should be a link between TSO and whether
> the serialization page trick works.  Second depends, as you say,
> on the OS implementation.

My limited understanding is that on RMO-based systems the requirements for:

"Synchronization based on page-protections - mprotect()"

as described in:

http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt

may not always hold. Dave Dice would need to provide more details if needed.

Cheers,
David

> I would assume that the write to the serialization page causes
> the OS to generate a new TLB entry or the like, involving the
> use of a ptwsync instruction which would be fine.  But we are
> investigating this.
>
> We are also experimenting with a small regression test to find
> out whether the  serialization page ever fails.
>
> Best regards,
>    Goetz.
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Montag, 20. Januar 2014 03:45
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>
> On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I had a look at the first part of this issue: Whether StoreStore
>> is necessary in the interpreter.  Let's for now assume the serialization
>> page mechanism works on PPC.
>>
>> In the state transition leaving the VM state, which is executed in the
>> destructor, ThreadStateTransition::transition() is called, which executes
>>         if (UseMembar) {
>>           OrderAccess::fence();
>>         } else {
>>           os::write_memory_serialize_page(thread);
>>         }
>>
>> os:: write_memory_serialize_page() can not be considered a proper
>> MemBar, as it only serializes if another thread poisoned the page.
>> Thus it does not qualify to order the initialization and the publishing
>> of the object.
>>
>> You are right, if UseMembar is true, the StoreStore in the interpreter
>> is superfluous.  We could guard the StoreStores in the interpreter by
>> !UseMembar.
>
> My understanding, from our existing non-TSO system ports, is that the
> present assumption is that either:
>
> a) you have a TSO system, in which case you are probably using the
> serialization page, but you don't need any barrier to enforce ordering
> anyway; or
>
> b) you don't have a TSO system, you are using UseMembar==true and so you
> get a full fence inserted that enforces the ordering anyway.
>
> So the ordering requirements are satisfied by piggy-backing on the
> UseMembar setting that comes from the thread state transition code,
> which forms part of the "runtime entry" code. That's not to say that you
> will necessarily find this applied consistently in all places where it
> might be applied - nor will you necessarily find that this is common
> knowledge amongst VM engineers.
>
> Technically the storeStore barriers could be conditional on !UseMembar
> but that is redundant in the current usage.
>
>> But then again, one is to order the publishing of the thread states,
>> the other to enforce some Java semantics.  I don't know whether everybody
>> who changes in one place is aware of both issues.  But if you want to,
>> I'll add a !UseMembar in the interpreter.
>
> Here are my preferred options in order:
>
> 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers -
> rely on the piggy-backing effect.
>
> 2. Conditionalize the new storeStore barriers on !UseMembar. This
> unfortunately penalizes all platforms with a runtime check.
>
> 3. Add the storeStores unconditionally. This penalizes platforms that
> set UseMembar==true as we will now get two fences at runtime.
>
> I know we're talking about the interpreter here so performance is not
> exactly critical, but still ...
>
>> Maybe it would be a good idea
>> to document the double use in interfaceSupport.cpp, too.  And maybe
>> add an assertion of some kind.
>
> interfaceSupport doesn't know that other code piggy-backs on the fact
> state-transitions have full fences when UseMembar is true. If it is
> documented anywhere it should be in the interpreter (and any other
> places that makes the same assumption) - something like:
>
> // On non-TSO systems there can be additional ordering constraints
> // between Java-level actions (such as allocation and constructor
> // invocation) that in principle need explicit memory barriers.
> // However, on many non-TSO systems the thread-state transition logic
> // in the IRT_ENTRY code will insert a full fence due to the use of
> // UseMembar==true, which provides the necessary ordering guarantees.
>
>>
>> We're digging into the other issue currenty, whether the serialization page
>> works on ppc.  We understand your concerns and have no simple answer to
>> it right now.  At least, in our VM and in the port there are no known problems
>> with the state transitions.
>
> Even if the memory serialization page does not work, in a guaranteed
> sense, on PPC-AIX, it is extremely unlikely that testing would expose
> this. Also note that the memory serialization page behaviour is more a
> function of the OS - so it may be that AIX is different to linux in that
> regard.
>
> Cheers,
> David
> -----
>
>> Best regards,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 16. Januar 2014 19:16
>> To: David Holmes; Lindenmaier, Goetz
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
>> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>>
>> Changes are in C++ Interpreter so it does not affect Oracle VM.
>> But David has point here. I would like to hear the explanation too.
>>
>> BTW, I see that for ppc64:
>>
>> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>>
>> as result write_memory_serialize_page() is used in
>> ThreadStateTransition::transition().
>>
>> Is it not enough on PPC64?
>>
>> Thanks,
>> Vladimir
>>
>> On 1/15/14 9:30 PM, David Holmes wrote:
>>> Can I get some response on this please - specifically the redundancy wrt
>>> IRT_ENTRY actions.
>>>
>>> Thanks,
>>> David
>>>
>>> On 20/12/2013 11:55 AM, David Holmes wrote:
>>>> Still catching up ...
>>>>
>>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> this change adds StoreStore barriers after object initialization and
>>>>> after constructor calls in the C++ interpreter.  This assures no
>>>>> uninitialized
>>>>> objects or final fields are visible.
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>>>
>>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>>>> thread state transitions that already include a full "fence" so the
>>>> storestore barriers are redundant in those cases.
>>>>
>>>> The fastpath _new storestore seems okay.
>>>>
>>>> I don't know how handle_return gets used to know if it is reasonable or
>>>> not.
>>>>
>>>> I was trying, unsuccessfully, to examine the same code in the
>>>> templateInterpreter to see how it handles these cases as it naturally
>>>> has the same object-initialization-safety requirements (though these can
>>>> be handled in a number of different ways other than an unconditional
>>>> storestore barrier at the end of the initialization and construction
>>>> phases.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Please review and test this change.
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>

From david.holmes at oracle.com  Mon Jan 20 19:01:54 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jan 2014 13:01:54 +1000
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <52DD1646.8030505@oracle.com>
References: <52DD1646.8030505@oracle.com>
Message-ID: <52DDE322.9060108@oracle.com>

Hi Igor,

On 20/01/2014 10:27 PM, Igor Ignatyev wrote:
> Hi all,
>
> Please review patch:
>
> Problem:
> tests 'compiler/tiered/NonTieredLevelsTest.java' and
> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group

I don't see any direct JMX use in those tests. Is it coming in via the 
Whitebox API? That would be unfortunate.

Thanks,
David


> Fix:
> tests are added into 'need_compact3'
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482

From david.holmes at oracle.com  Mon Jan 20 20:54:53 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jan 2014 14:54:53 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5293FE15.9050100@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>
	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>
	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DDFD9D.3050205@oracle.com>

Hi Goetz,

On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I tried to come up with a webrev that implements the change as proposed in
> your mails:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>
> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
> support_IRIW_for_not_multiple_copy_atomic_cpu.

Given the flag name the commentary eg:

+       // Support ordering of "Independent Reads of Independent Writes".
+       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {

seems somewhat redundant.

> I left the definition and handling of _wrote_volatile in the code, without
> any protection.

+   bool          _wrote_volatile;     // Did we write a final field?

s/final/volatile

> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
> and put it on one line.
>
> I removed the comment in library_call.cpp.
> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
> from the comments as it's PPC specific.

I think the primary IRIW comment/explanation should go in 
globalDefinitions.hpp where 
support_IRIW_for_not_multiple_copy_atomic_cpu is defined.

> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
> issues in C1 if nobody did it by then.

I've filed:

https://bugs.openjdk.java.net/browse/JDK-8032366

"Implement C1 support for IRIW conformance on non-multiple-copy-atomic 
platforms"

to cover this task, as it may be needed sooner rather than later.

> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
> performance problems arise, we still can add #ifdef PPC64 to circumvent this.

Ok.

Thanks,
David

> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 16. Januar 2014 10:05
> To: Vladimir Kozlov
> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>> On 1/16/14 12:34 AM, David Holmes wrote:
>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>> want to keep it this way, it could be useful to have such info on other
>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>> parse.hpp.
>>>>
>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>> which could be checked in all places instead of #ifdef:
>>>
>>> I asked for the ifdef some time back as I find it much preferable to
>>> have this as a build-time construct rather than a
>>> runtime one. I don't want to have to pay anything for this if we don't
>>> use it.
>>
>> Any decent C++ compiler will optimize expressions with such constants
>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>
> If you insist then we may as well do it all the same way. Better to be
> consistent.
>
> My apologies Goetz for wasting your time going back and forth on this.
>
> That aside I have a further concern with this IRIW support - it is
> incomplete as there is no C1 support, as PPC64 isn't using client. If
> this is going on then we (which probably means the Oracle 'we') need to
> add the missing C1 code.
>
> David
> -----
>
>> Vladimir
>>
>>>
>>> David
>>>
>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>> #else
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>> #endif
>>>>
>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>
>>>> and then:
>>>>
>>>>    #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>      oop p = JNIHandles::resolve(obj); \
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>> OrderAccess::fence(); \
>>>>      volatile type_name v = OrderAccess::load_acquire((volatile
>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>
>>>> And:
>>>>
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>> field->is_volatile()) {
>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>> +  }
>>>>
>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>
>>>> The code in parse1.cpp could be put on one line:
>>>>
>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>> method()->is_initializer()) )) {
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> I updated the webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>
>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>     reflect the new flagging.  Also I mention that we support the
>>>>>>     volatile constructor issue, but that it's not standard.
>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>     I also think it's better to separate these this way.
>>>>>
>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>> please.
>>>>>
>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>> comment doesn't make much sense to me and refers to
>>>>> ppc specific stuff in a shared file:
>>>>>
>>>>>       if (is_volatile) {
>>>>> !     if (!is_store) {
>>>>>           insert_mem_bar(Op_MemBarAcquire);
>>>>> !     } else {
>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>           insert_mem_bar(Op_MemBarVolatile);
>>>>> + #endif
>>>>> +     }
>>>>>
>>>>> I don't think the comment is needed.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks for your comments!
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> Sorry for the delay in getting back to this.
>>>>>>
>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>> specifically it is
>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>> Seems
>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>
>>>>>> The changes related to volatile writes in the constructor, as
>>>>>> discussed
>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>> PPC64 porters.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>> this version.
>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lindenmaier, Goetz
>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>> To: David Holmes
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>> not
>>>>>>>> required to pass.
>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>> worked
>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>> it by
>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>> part is
>>>>>>> not that performance relevant.
>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz
>>>>>>>
>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>> emails.
>>>>>>>
>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>> settled.
>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>
>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>> The change is about IRIW.
>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>
>>>>>>> This is the part I still have some question marks over as the
>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>> But I'm
>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>
>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>> stores.
>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>> constructor tests.
>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>> after stores
>>>>>>>>          to pass the volatile constructor tests.
>>>>>>>
>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>> were not
>>>>>>> required to pass.
>>>>>>>
>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>> order
>>>>>>>> instructions are not as find-granular as the
>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>> The only instruction
>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>> therefore the
>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>> proper representation
>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>> it's pointless
>>>>>>>> anyways.
>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>> I'd be happy to add a property
>>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>
>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>> think
>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>> Or also
>>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> TL;DR version:
>>>>>>>>
>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>> constructor-barrier
>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>> *may*
>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>> ensure
>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>> invalid
>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>> need it
>>>>>>>> due to other factors).
>>>>>>>>
>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>> term :)
>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>
>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>> visible to
>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>> architectures
>>>>>>>> are not multiple-copy atomic."
>>>>>>>>
>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>> ARM and
>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>> current issue is what you wrote below:
>>>>>>>>
>>>>>>>>      > The fixes for the constructor issue are only needed because we
>>>>>>>>      > remove the sync instruction from behind stores
>>>>>>>> (parse3.cpp:320)
>>>>>>>>      > and place it before loads.
>>>>>>>>
>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>> after
>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>> same
>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>> load -
>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>> clearer.
>>>>>>>>
>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>> implemented as
>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>> hooks
>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>
>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>> this
>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>
>>>>>>>>> I did not yet add the
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>> or
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>
>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>
>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>> store
>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>> (volatile store in constructor).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>> issue.
>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>> you
>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>> solution,
>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>> issues.
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>> and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>> ARM and
>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>> Work-Stealing for
>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>> taskqueue problem.
>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>
>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>> used 'read'
>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>> above).
>>>>>>>>>
>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>> processors
>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>> Aleksey!)
>>>>>>>>>
>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>
>>>>>>>>>> -- IRIW issue
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>> a few
>>>>>>>>>>> moments thought.
>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>> problem yet,
>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>
>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>> continuous.
>>>>>>>>>
>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?)
>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>> I contributed a
>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>> nice, I admit.
>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>> are evaluated
>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>
>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>> problem
>>>>>>>>>> is that
>>>>>>>>>>         store
>>>>>>>>>>         sync
>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>> only
>>>>>>>>>>         sync
>>>>>>>>>>         load
>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>> pass that test.
>>>>>>>>>
>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>> term and
>>>>>>>>> can't find any reference to it.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>         The JMM is fine. And
>>>>>>>>>>         store
>>>>>>>>>>         MemBarVolatile
>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>> that
>>>>>>>>>> do what is required.
>>>>>>>>>>
>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>
>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>
>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>> initializing
>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>> Shipilev
>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>           LongVolatileTest
>>>>>>>>>>>           AtomicIntegerInitialValueTest
>>>>>>>>>>> will fail.
>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>> volatile field would be
>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>
>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>> volatiles do
>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>> that
>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>> Aleksey
>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>
>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>> heavyweight
>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>> don't
>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>
>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>> account
>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>> different platforms
>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>> An example:
>>>>>>>>>>>          MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>          MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>> this:
>>>>>>>>>>>          MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>          MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>           MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>          MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>> can not implement
>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>
>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>> issue.
>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>> read
>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>
>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>> independent?
>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>
>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>> few
>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>> will
>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>> moment. The
>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>> requirements for
>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>> are not
>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>> store
>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>> of the
>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>> software
>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>> don't have
>>>>>>>>>> that on ppc!)
>>>>>>>>>>
>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>> I will
>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -- Other ports:
>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>> it might
>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>> them).
>>>>>>>>>>>
>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>> can
>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>> way :)
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>
>>>>>>>>>>>         From what I understand what we see here is an attempt to
>>>>>>>>>>> fix an
>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>> IRIW
>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>> doing the
>>>>>>>>>>> load.
>>>>>>>>>>>
>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>> would be
>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>> performance
>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>> that
>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>> this is
>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>> with the
>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>> the
>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>> properties
>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>> on a
>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>> reduce
>>>>>>>>>>> to a no-op.
>>>>>>>>>>>
>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>> under
>>>>>>>>>>> the JMM.
>>>>>>>>>>>
>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>> current
>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>> is set
>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>
>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>
>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>> Java
>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>> explicitly
>>>>>>>>>>> like this.
>>>>>>>>>>>
>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>> there
>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>> defines?
>>>>>>>>>>>>         From what I understand our ppc port is also affected.
>>>>>>>>>>>> David?
>>>>>>>>>>>
>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>
>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>> specific which
>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>
>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>
>>>>>>>>>>>>            if (is_vol) {
>>>>>>>>>>>>              // See comment in do_get_xxx().
>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>              insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>> #else
>>>>>>>>>>>>              if (is_field) {
>>>>>>>>>>>>                // Add MemBarRelease for constructors which write
>>>>>>>>>>>> volatile field
>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>                set_wrote_volatile(true);
>>>>>>>>>>>>              }
>>>>>>>>>>>> #endif
>>>>>>>>>>>>            }
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Example:
>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>           __________    __________    __________    __________
>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>
>>>>>>>>>>>>>            write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>                          read(y)                     read(x)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>> is only
>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>> threads
>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>> fields
>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>> published.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>> seems too
>>>>>>>>>>>>> strong.
>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>

From goetz.lindenmaier at sap.com  Tue Jan 21 01:22:08 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 21 Jan 2014 09:22:08 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52DDFD9D.3050205@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5293FE15.9050100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>

Hi,

I made a new webrev
http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
differing from  
http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
only in the comments.

I removed 
// Support ordering of "Independent Reads of Independent Writes". 
everywhere, and edited the comments in the globalDefinition*.hpp
files.

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 21. Januar 2014 05:55
To: Lindenmaier, Goetz; Vladimir Kozlov
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Hi Goetz,

On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I tried to come up with a webrev that implements the change as proposed in
> your mails:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>
> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
> support_IRIW_for_not_multiple_copy_atomic_cpu.

Given the flag name the commentary eg:

+       // Support ordering of "Independent Reads of Independent Writes".
+       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {

seems somewhat redundant.

> I left the definition and handling of _wrote_volatile in the code, without
> any protection.

+   bool          _wrote_volatile;     // Did we write a final field?

s/final/volatile

> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
> and put it on one line.
>
> I removed the comment in library_call.cpp.
> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
> from the comments as it's PPC specific.

I think the primary IRIW comment/explanation should go in 
globalDefinitions.hpp where 
support_IRIW_for_not_multiple_copy_atomic_cpu is defined.

> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
> issues in C1 if nobody did it by then.

I've filed:

https://bugs.openjdk.java.net/browse/JDK-8032366

"Implement C1 support for IRIW conformance on non-multiple-copy-atomic 
platforms"

to cover this task, as it may be needed sooner rather than later.

> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
> performance problems arise, we still can add #ifdef PPC64 to circumvent this.

Ok.

Thanks,
David

> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 16. Januar 2014 10:05
> To: Vladimir Kozlov
> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>> On 1/16/14 12:34 AM, David Holmes wrote:
>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>> want to keep it this way, it could be useful to have such info on other
>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>> parse.hpp.
>>>>
>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>> which could be checked in all places instead of #ifdef:
>>>
>>> I asked for the ifdef some time back as I find it much preferable to
>>> have this as a build-time construct rather than a
>>> runtime one. I don't want to have to pay anything for this if we don't
>>> use it.
>>
>> Any decent C++ compiler will optimize expressions with such constants
>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>
> If you insist then we may as well do it all the same way. Better to be
> consistent.
>
> My apologies Goetz for wasting your time going back and forth on this.
>
> That aside I have a further concern with this IRIW support - it is
> incomplete as there is no C1 support, as PPC64 isn't using client. If
> this is going on then we (which probably means the Oracle 'we') need to
> add the missing C1 code.
>
> David
> -----
>
>> Vladimir
>>
>>>
>>> David
>>>
>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>> #else
>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>> #endif
>>>>
>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>
>>>> and then:
>>>>
>>>>    #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>      oop p = JNIHandles::resolve(obj); \
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>> OrderAccess::fence(); \
>>>>      volatile type_name v = OrderAccess::load_acquire((volatile
>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>
>>>> And:
>>>>
>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>> field->is_volatile()) {
>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>> +  }
>>>>
>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>
>>>> The code in parse1.cpp could be put on one line:
>>>>
>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>> method()->is_initializer()) )) {
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> I updated the webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>
>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>     reflect the new flagging.  Also I mention that we support the
>>>>>>     volatile constructor issue, but that it's not standard.
>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>     I also think it's better to separate these this way.
>>>>>
>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>> please.
>>>>>
>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>> comment doesn't make much sense to me and refers to
>>>>> ppc specific stuff in a shared file:
>>>>>
>>>>>       if (is_volatile) {
>>>>> !     if (!is_store) {
>>>>>           insert_mem_bar(Op_MemBarAcquire);
>>>>> !     } else {
>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>           insert_mem_bar(Op_MemBarVolatile);
>>>>> + #endif
>>>>> +     }
>>>>>
>>>>> I don't think the comment is needed.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks for your comments!
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> Sorry for the delay in getting back to this.
>>>>>>
>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>> specifically it is
>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>> Seems
>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>
>>>>>> The changes related to volatile writes in the constructor, as
>>>>>> discussed
>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>> PPC64 porters.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>> this version.
>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lindenmaier, Goetz
>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>> To: David Holmes
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>> not
>>>>>>>> required to pass.
>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>> worked
>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>> it by
>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>> part is
>>>>>>> not that performance relevant.
>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz
>>>>>>>
>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>> emails.
>>>>>>>
>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>> settled.
>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>
>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>> The change is about IRIW.
>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>
>>>>>>> This is the part I still have some question marks over as the
>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>> But I'm
>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>
>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>> stores.
>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>> constructor tests.
>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>> after stores
>>>>>>>>          to pass the volatile constructor tests.
>>>>>>>
>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>> were not
>>>>>>> required to pass.
>>>>>>>
>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>> order
>>>>>>>> instructions are not as find-granular as the
>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>> The only instruction
>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>> therefore the
>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>> proper representation
>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>> it's pointless
>>>>>>>> anyways.
>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>> I'd be happy to add a property
>>>>>>>>       OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>
>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>> think
>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>> Or also
>>>>>>>>        OrderAccess::needs_support_iriw_ordering()
>>>>>>>>        VM_Version::needs_support_iriw_ordering()
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> TL;DR version:
>>>>>>>>
>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>> constructor-barrier
>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>> *may*
>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>> ensure
>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>> invalid
>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>> need it
>>>>>>>> due to other factors).
>>>>>>>>
>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>> term :)
>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>
>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>> visible to
>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>> architectures
>>>>>>>> are not multiple-copy atomic."
>>>>>>>>
>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>> ARM and
>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>> current issue is what you wrote below:
>>>>>>>>
>>>>>>>>      > The fixes for the constructor issue are only needed because we
>>>>>>>>      > remove the sync instruction from behind stores
>>>>>>>> (parse3.cpp:320)
>>>>>>>>      > and place it before loads.
>>>>>>>>
>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>> after
>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>> same
>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>> load -
>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>> clearer.
>>>>>>>>
>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>> implemented as
>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>> hooks
>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>
>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>> this
>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>
>>>>>>>>> I did not yet add the
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>> or
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>
>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>
>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>> store
>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>> (volatile store in constructor).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>> issue.
>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>> you
>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>> solution,
>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>> issues.
>>>>>>>>>
>>>>>>>>> @David
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>> and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>> ARM and
>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>> Work-Stealing for
>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>> taskqueue problem.
>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>
>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>> used 'read'
>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>> above).
>>>>>>>>>
>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>> processors
>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>> Aleksey!)
>>>>>>>>>
>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>
>>>>>>>>>> -- IRIW issue
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>> a few
>>>>>>>>>>> moments thought.
>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>> problem yet,
>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>
>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>> continuous.
>>>>>>>>>
>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?)
>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>> I contributed a
>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>> nice, I admit.
>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>> are evaluated
>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>
>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>> problem
>>>>>>>>>> is that
>>>>>>>>>>         store
>>>>>>>>>>         sync
>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>> only
>>>>>>>>>>         sync
>>>>>>>>>>         load
>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>> pass that test.
>>>>>>>>>
>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>> term and
>>>>>>>>> can't find any reference to it.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>         The JMM is fine. And
>>>>>>>>>>         store
>>>>>>>>>>         MemBarVolatile
>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>> that
>>>>>>>>>> do what is required.
>>>>>>>>>>
>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>
>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>
>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>> initializing
>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>> Shipilev
>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>           LongVolatileTest
>>>>>>>>>>>           AtomicIntegerInitialValueTest
>>>>>>>>>>> will fail.
>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>> volatile field would be
>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>
>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>> volatiles do
>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>> that
>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>> Aleksey
>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>
>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>> heavyweight
>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>> don't
>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>
>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>> account
>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>> different platforms
>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>> An example:
>>>>>>>>>>>          MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>          MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>> this:
>>>>>>>>>>>          MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>          MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>           MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>          MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>> can not implement
>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>
>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>> issue.
>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>> read
>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>
>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>> independent?
>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>
>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>> few
>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>> will
>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>> moment. The
>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>> requirements for
>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>> are not
>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>> store
>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>> of the
>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>> software
>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>> don't have
>>>>>>>>>> that on ppc!)
>>>>>>>>>>
>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>> I will
>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -- Other ports:
>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>> it might
>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>> them).
>>>>>>>>>>>
>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>> can
>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>> way :)
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>
>>>>>>>>>>>         From what I understand what we see here is an attempt to
>>>>>>>>>>> fix an
>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>> IRIW
>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>> doing the
>>>>>>>>>>> load.
>>>>>>>>>>>
>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>> would be
>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>> performance
>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>> that
>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>> this is
>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>> with the
>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>> the
>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>> properties
>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>> on a
>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>> reduce
>>>>>>>>>>> to a no-op.
>>>>>>>>>>>
>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>> under
>>>>>>>>>>> the JMM.
>>>>>>>>>>>
>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>> current
>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>> is set
>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>
>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>
>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>> Java
>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>> explicitly
>>>>>>>>>>> like this.
>>>>>>>>>>>
>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>> there
>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>> defines?
>>>>>>>>>>>>         From what I understand our ppc port is also affected.
>>>>>>>>>>>> David?
>>>>>>>>>>>
>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>
>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>> specific which
>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>
>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>
>>>>>>>>>>>>            if (is_vol) {
>>>>>>>>>>>>              // See comment in do_get_xxx().
>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>              insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>> #else
>>>>>>>>>>>>              if (is_field) {
>>>>>>>>>>>>                // Add MemBarRelease for constructors which write
>>>>>>>>>>>> volatile field
>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>                set_wrote_volatile(true);
>>>>>>>>>>>>              }
>>>>>>>>>>>> #endif
>>>>>>>>>>>>            }
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Example:
>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>           __________    __________    __________    __________
>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>
>>>>>>>>>>>>>            write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>                          read(y)                     read(x)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>> is only
>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>> threads
>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>> fields
>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>> published.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>> seems too
>>>>>>>>>>>>> strong.
>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>

From igor.ignatyev at oracle.com  Tue Jan 21 01:41:45 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 21 Jan 2014 13:41:45 +0400
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <52DDE322.9060108@oracle.com>
References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com>
Message-ID: <52DE40D9.6090604@oracle.com>

Hi David,

Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest, 
super-class of these tests, uses it.

Igor

On 01/21/2014 07:01 AM, David Holmes wrote:
> Hi Igor,
>
> On 20/01/2014 10:27 PM, Igor Ignatyev wrote:
>> Hi all,
>>
>> Please review patch:
>>
>> Problem:
>> tests 'compiler/tiered/NonTieredLevelsTest.java' and
>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group
>
> I don't see any direct JMX use in those tests. Is it coming in via the
> Whitebox API? That would be unfortunate.
>
> Thanks,
> David
>
>
>> Fix:
>> tests are added into 'need_compact3'
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482

From david.holmes at oracle.com  Tue Jan 21 03:53:20 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jan 2014 21:53:20 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<52948FF1.5080300@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>
	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>
	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DE5FB0.5000808@oracle.com>

Thanks Goetz!

This typo still exists:

+   bool          _wrote_volatile;     // Did we write a final field?

s/final/volatile/

Otherwise no further comments from me.

David

On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I made a new webrev
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
> differing from
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
> only in the comments.
>
> I removed
> // Support ordering of "Independent Reads of Independent Writes".
> everywhere, and edited the comments in the globalDefinition*.hpp
> files.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 21. Januar 2014 05:55
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi Goetz,
>
> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I tried to come up with a webrev that implements the change as proposed in
>> your mails:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>
>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>
> Given the flag name the commentary eg:
>
> +       // Support ordering of "Independent Reads of Independent Writes".
> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>
> seems somewhat redundant.
>
>> I left the definition and handling of _wrote_volatile in the code, without
>> any protection.
>
> +   bool          _wrote_volatile;     // Did we write a final field?
>
> s/final/volatile
>
>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>> and put it on one line.
>>
>> I removed the comment in library_call.cpp.
>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>> from the comments as it's PPC specific.
>
> I think the primary IRIW comment/explanation should go in
> globalDefinitions.hpp where
> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>
>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>> issues in C1 if nobody did it by then.
>
> I've filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8032366
>
> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
> platforms"
>
> to cover this task, as it may be needed sooner rather than later.
>
>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>
> Ok.
>
> Thanks,
> David
>
>> Best regards,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 16. Januar 2014 10:05
>> To: Vladimir Kozlov
>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>> want to keep it this way, it could be useful to have such info on other
>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>> parse.hpp.
>>>>>
>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>> which could be checked in all places instead of #ifdef:
>>>>
>>>> I asked for the ifdef some time back as I find it much preferable to
>>>> have this as a build-time construct rather than a
>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>> use it.
>>>
>>> Any decent C++ compiler will optimize expressions with such constants
>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>
>> If you insist then we may as well do it all the same way. Better to be
>> consistent.
>>
>> My apologies Goetz for wasting your time going back and forth on this.
>>
>> That aside I have a further concern with this IRIW support - it is
>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>> this is going on then we (which probably means the Oracle 'we') need to
>> add the missing C1 code.
>>
>> David
>> -----
>>
>>> Vladimir
>>>
>>>>
>>>> David
>>>>
>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>> #else
>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>> #endif
>>>>>
>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>
>>>>> and then:
>>>>>
>>>>>     #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>       oop p = JNIHandles::resolve(obj); \
>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>> OrderAccess::fence(); \
>>>>>       volatile type_name v = OrderAccess::load_acquire((volatile
>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>
>>>>> And:
>>>>>
>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>> field->is_volatile()) {
>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>> +  }
>>>>>
>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>
>>>>> The code in parse1.cpp could be put on one line:
>>>>>
>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>> method()->is_initializer()) )) {
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I updated the webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>      reflect the new flagging.  Also I mention that we support the
>>>>>>>      volatile constructor issue, but that it's not standard.
>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>      I also think it's better to separate these this way.
>>>>>>
>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>> please.
>>>>>>
>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>> comment doesn't make much sense to me and refers to
>>>>>> ppc specific stuff in a shared file:
>>>>>>
>>>>>>        if (is_volatile) {
>>>>>> !     if (!is_store) {
>>>>>>            insert_mem_bar(Op_MemBarAcquire);
>>>>>> !     } else {
>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>            insert_mem_bar(Op_MemBarVolatile);
>>>>>> + #endif
>>>>>> +     }
>>>>>>
>>>>>> I don't think the comment is needed.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Thanks for your comments!
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi Goetz,
>>>>>>>
>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>
>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>> specifically it is
>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>> Seems
>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>
>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>> discussed
>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>> PPC64 porters.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>> this version.
>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>> To: David Holmes
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>> not
>>>>>>>>> required to pass.
>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>> worked
>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>> it by
>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>> part is
>>>>>>>> not that performance relevant.
>>>>>>>>
>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>> think
>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz
>>>>>>>>
>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>> emails.
>>>>>>>>
>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>> settled.
>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>
>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>> The change is about IRIW.
>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>
>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>> But I'm
>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>
>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>> stores.
>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>> constructor tests.
>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>> after stores
>>>>>>>>>           to pass the volatile constructor tests.
>>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>> were not
>>>>>>>> required to pass.
>>>>>>>>
>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>> order
>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>> The only instruction
>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>> therefore the
>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>> proper representation
>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>> it's pointless
>>>>>>>>> anyways.
>>>>>>>>>
>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>> I'd be happy to add a property
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>> Or also
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> TL;DR version:
>>>>>>>>>
>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>> constructor-barrier
>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>> *may*
>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>> ensure
>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>> invalid
>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>> need it
>>>>>>>>> due to other factors).
>>>>>>>>>
>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>> term :)
>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>
>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>> visible to
>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>> architectures
>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>
>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>> ARM and
>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>
>>>>>>>>>       > The fixes for the constructor issue are only needed because we
>>>>>>>>>       > remove the sync instruction from behind stores
>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>       > and place it before loads.
>>>>>>>>>
>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>> after
>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>> same
>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>> load -
>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>> clearer.
>>>>>>>>>
>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>> implemented as
>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>> hooks
>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>> this
>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>
>>>>>>>>>> I did not yet add the
>>>>>>>>>>          OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>          VM_Version::needs_support_iriw_ordering()
>>>>>>>>>> or
>>>>>>>>>>         OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>
>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>
>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>> store
>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @David
>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>> continuous.
>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>> issue.
>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>> you
>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>> solution,
>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>> issues.
>>>>>>>>>>
>>>>>>>>>> @David
>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>> and
>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>> ARM and
>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>> Work-Stealing for
>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>> taskqueue problem.
>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>
>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>> used 'read'
>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>> above).
>>>>>>>>>>
>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>> processors
>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>> Aleksey!)
>>>>>>>>>>
>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>
>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>> a few
>>>>>>>>>>>> moments thought.
>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>> problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>>>
>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>> different?)
>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>> I contributed a
>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>> nice, I admit.
>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>> are evaluated
>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>
>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>> problem
>>>>>>>>>>> is that
>>>>>>>>>>>          store
>>>>>>>>>>>          sync
>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>> only
>>>>>>>>>>>          sync
>>>>>>>>>>>          load
>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>> pass that test.
>>>>>>>>>>
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>> term and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>          The JMM is fine. And
>>>>>>>>>>>          store
>>>>>>>>>>>          MemBarVolatile
>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>> that
>>>>>>>>>>> do what is required.
>>>>>>>>>>>
>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>
>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>> initializing
>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>> Shipilev
>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>            LongVolatileTest
>>>>>>>>>>>>            AtomicIntegerInitialValueTest
>>>>>>>>>>>> will fail.
>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>
>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>> volatiles do
>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>> that
>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>> Aleksey
>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>
>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>> don't
>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>
>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>> account
>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>> different platforms
>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>> An example:
>>>>>>>>>>>>           MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>           MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>> this:
>>>>>>>>>>>>           MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>           MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>            MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>           MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>> can not implement
>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>
>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>> issue.
>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>> read
>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>
>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>> independent?
>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>> few
>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>> will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>> moment. The
>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>> requirements for
>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>> are not
>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>> store
>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>> of the
>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>> software
>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>> don't have
>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>
>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>> I will
>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>> it might
>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>> them).
>>>>>>>>>>>>
>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>> can
>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>> way :)
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>
>>>>>>>>>>>>          From what I understand what we see here is an attempt to
>>>>>>>>>>>> fix an
>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>> IRIW
>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>> doing the
>>>>>>>>>>>> load.
>>>>>>>>>>>>
>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>> would be
>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>> performance
>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>> that
>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>> this is
>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>> with the
>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>> the
>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>> properties
>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>> on a
>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>> reduce
>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>
>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>> under
>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>
>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>> current
>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>> is set
>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>
>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>
>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>> Java
>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>> explicitly
>>>>>>>>>>>> like this.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>> there
>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>> defines?
>>>>>>>>>>>>>          From what I understand our ppc port is also affected.
>>>>>>>>>>>>> David?
>>>>>>>>>>>>
>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>> specific which
>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>             if (is_vol) {
>>>>>>>>>>>>>               // See comment in do_get_xxx().
>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>> #else
>>>>>>>>>>>>>               if (is_field) {
>>>>>>>>>>>>>                 // Add MemBarRelease for constructors which write
>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>                 set_wrote_volatile(true);
>>>>>>>>>>>>>               }
>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>             }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>            __________    __________    __________    __________
>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>                           read(y)                     read(x)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>

From david.holmes at oracle.com  Tue Jan 21 03:55:28 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jan 2014 21:55:28 +1000
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <52DE40D9.6090604@oracle.com>
References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com>
	<52DE40D9.6090604@oracle.com>
Message-ID: <52DE6030.4090500@oracle.com>

On 21/01/2014 7:41 PM, Igor Ignatyev wrote:
> Hi David,
>
> Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest,
> super-class of these tests, uses it.

I see. That is unfortunate as it constrains the test environment for 
users of the Whitebox API even if they don't need the JMX part directly. 
Whomever owns this should see if they can rectify this some how.

Thanks,
David

> Igor
>
> On 01/21/2014 07:01 AM, David Holmes wrote:
>> Hi Igor,
>>
>> On 20/01/2014 10:27 PM, Igor Ignatyev wrote:
>>> Hi all,
>>>
>>> Please review patch:
>>>
>>> Problem:
>>> tests 'compiler/tiered/NonTieredLevelsTest.java' and
>>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group
>>
>> I don't see any direct JMX use in those tests. Is it coming in via the
>> Whitebox API? That would be unfortunate.
>>
>> Thanks,
>> David
>>
>>
>>> Fix:
>>> tests are added into 'need_compact3'
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482

From igor.ignatyev at oracle.com  Tue Jan 21 05:04:33 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 21 Jan 2014 17:04:33 +0400
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <52DE6030.4090500@oracle.com>
References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com>
	<52DE40D9.6090604@oracle.com> <52DE6030.4090500@oracle.com>
Message-ID: <52DE7061.2050607@oracle.com>

I will file an RFE to get rid of JMX in CompilerWhiteBoxTest.

Can I count you as an reviewer?

Igor

On 01/21/2014 03:55 PM, David Holmes wrote:
> On 21/01/2014 7:41 PM, Igor Ignatyev wrote:
>> Hi David,
>>
>> Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest,
>> super-class of these tests, uses it.
>
> I see. That is unfortunate as it constrains the test environment for
> users of the Whitebox API even if they don't need the JMX part directly.
> Whomever owns this should see if they can rectify this some how.
>
> Thanks,
> David
>
>> Igor
>>
>> On 01/21/2014 07:01 AM, David Holmes wrote:
>>> Hi Igor,
>>>
>>> On 20/01/2014 10:27 PM, Igor Ignatyev wrote:
>>>> Hi all,
>>>>
>>>> Please review patch:
>>>>
>>>> Problem:
>>>> tests 'compiler/tiered/NonTieredLevelsTest.java' and
>>>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group
>>>
>>> I don't see any direct JMX use in those tests. Is it coming in via the
>>> Whitebox API? That would be unfortunate.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Fix:
>>>> tests are added into 'need_compact3'
>>>>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482

From igor.ignatyev at oracle.com  Tue Jan 21 05:05:57 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 21 Jan 2014 17:05:57 +0400
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <7584D6FF-25B8-40BD-AFF6-593BFBD341AB@oracle.com>
References: <52DD1646.8030505@oracle.com>
	<DC434523-81B2-43B6-B113-5A683C2C8585@oracle.com>
	<7584D6FF-25B8-40BD-AFF6-593BFBD341AB@oracle.com>
Message-ID: <52DE70B5.8020000@oracle.com>

Roland/Staffan
Thanks for reviewing this.

Igor

On 01/20/2014 10:02 PM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 20 jan 2014, at 17:21, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
>>
>> That looks good to me.
>>
>> Roland.
>>
>

From goetz.lindenmaier at sap.com  Tue Jan 21 05:19:28 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 21 Jan 2014 13:19:28 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52DE5FB0.5000808@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<52948FF1.5080300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
	<52DE5FB0.5000808@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>

Sorry, I missed that.  fixed.

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 21. Januar 2014 12:53
To: Lindenmaier, Goetz; Vladimir Kozlov
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Thanks Goetz!

This typo still exists:

+   bool          _wrote_volatile;     // Did we write a final field?

s/final/volatile/

Otherwise no further comments from me.

David

On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I made a new webrev
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
> differing from
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
> only in the comments.
>
> I removed
> // Support ordering of "Independent Reads of Independent Writes".
> everywhere, and edited the comments in the globalDefinition*.hpp
> files.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 21. Januar 2014 05:55
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi Goetz,
>
> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I tried to come up with a webrev that implements the change as proposed in
>> your mails:
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>
>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>
> Given the flag name the commentary eg:
>
> +       // Support ordering of "Independent Reads of Independent Writes".
> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>
> seems somewhat redundant.
>
>> I left the definition and handling of _wrote_volatile in the code, without
>> any protection.
>
> +   bool          _wrote_volatile;     // Did we write a final field?
>
> s/final/volatile
>
>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>> and put it on one line.
>>
>> I removed the comment in library_call.cpp.
>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>> from the comments as it's PPC specific.
>
> I think the primary IRIW comment/explanation should go in
> globalDefinitions.hpp where
> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>
>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>> issues in C1 if nobody did it by then.
>
> I've filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8032366
>
> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
> platforms"
>
> to cover this task, as it may be needed sooner rather than later.
>
>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>
> Ok.
>
> Thanks,
> David
>
>> Best regards,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 16. Januar 2014 10:05
>> To: Vladimir Kozlov
>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>> want to keep it this way, it could be useful to have such info on other
>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>> parse.hpp.
>>>>>
>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>> which could be checked in all places instead of #ifdef:
>>>>
>>>> I asked for the ifdef some time back as I find it much preferable to
>>>> have this as a build-time construct rather than a
>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>> use it.
>>>
>>> Any decent C++ compiler will optimize expressions with such constants
>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>
>> If you insist then we may as well do it all the same way. Better to be
>> consistent.
>>
>> My apologies Goetz for wasting your time going back and forth on this.
>>
>> That aside I have a further concern with this IRIW support - it is
>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>> this is going on then we (which probably means the Oracle 'we') need to
>> add the missing C1 code.
>>
>> David
>> -----
>>
>>> Vladimir
>>>
>>>>
>>>> David
>>>>
>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>> #else
>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>> #endif
>>>>>
>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>
>>>>> and then:
>>>>>
>>>>>     #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>       oop p = JNIHandles::resolve(obj); \
>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>> OrderAccess::fence(); \
>>>>>       volatile type_name v = OrderAccess::load_acquire((volatile
>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>
>>>>> And:
>>>>>
>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>> field->is_volatile()) {
>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>> +  }
>>>>>
>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>
>>>>> The code in parse1.cpp could be put on one line:
>>>>>
>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>> method()->is_initializer()) )) {
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I updated the webrev:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>
>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>      reflect the new flagging.  Also I mention that we support the
>>>>>>>      volatile constructor issue, but that it's not standard.
>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>      I also think it's better to separate these this way.
>>>>>>
>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>> please.
>>>>>>
>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>> comment doesn't make much sense to me and refers to
>>>>>> ppc specific stuff in a shared file:
>>>>>>
>>>>>>        if (is_volatile) {
>>>>>> !     if (!is_store) {
>>>>>>            insert_mem_bar(Op_MemBarAcquire);
>>>>>> !     } else {
>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>            insert_mem_bar(Op_MemBarVolatile);
>>>>>> + #endif
>>>>>> +     }
>>>>>>
>>>>>> I don't think the comment is needed.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Thanks for your comments!
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> Hi Goetz,
>>>>>>>
>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>
>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>> specifically it is
>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>> Seems
>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>
>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>> discussed
>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>> PPC64 porters.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>> this version.
>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>> To: David Holmes
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>> not
>>>>>>>>> required to pass.
>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>> worked
>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>> it by
>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>> part is
>>>>>>>> not that performance relevant.
>>>>>>>>
>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>> think
>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz
>>>>>>>>
>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>> emails.
>>>>>>>>
>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>> settled.
>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>
>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>> The change is about IRIW.
>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>
>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>> But I'm
>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>
>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>> stores.
>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>> constructor tests.
>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>> after stores
>>>>>>>>>           to pass the volatile constructor tests.
>>>>>>>>
>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>> were not
>>>>>>>> required to pass.
>>>>>>>>
>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>> order
>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>> The only instruction
>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>> therefore the
>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>> proper representation
>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>> it's pointless
>>>>>>>>> anyways.
>>>>>>>>>
>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>> I'd be happy to add a property
>>>>>>>>>        OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>
>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>> think
>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>> Or also
>>>>>>>>>         OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>         VM_Version::needs_support_iriw_ordering()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> TL;DR version:
>>>>>>>>>
>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>> constructor-barrier
>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>> *may*
>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>> ensure
>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>> invalid
>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>> need it
>>>>>>>>> due to other factors).
>>>>>>>>>
>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>> term :)
>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>
>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>> visible to
>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>> architectures
>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>
>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>> ARM and
>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>
>>>>>>>>>       > The fixes for the constructor issue are only needed because we
>>>>>>>>>       > remove the sync instruction from behind stores
>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>       > and place it before loads.
>>>>>>>>>
>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>> after
>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>> same
>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>> load -
>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>> clearer.
>>>>>>>>>
>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>> implemented as
>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>> hooks
>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>
>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>> this
>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>
>>>>>>>>>> I did not yet add the
>>>>>>>>>>          OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>          VM_Version::needs_support_iriw_ordering()
>>>>>>>>>> or
>>>>>>>>>>         OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>
>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>
>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>> store
>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @David
>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>> continuous.
>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>> issue.
>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>> you
>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>> solution,
>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>> issues.
>>>>>>>>>>
>>>>>>>>>> @David
>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>> and
>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>> ARM and
>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>> Work-Stealing for
>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>> taskqueue problem.
>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>
>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>> used 'read'
>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>> above).
>>>>>>>>>>
>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>> processors
>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>> Aleksey!)
>>>>>>>>>>
>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>
>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>> a few
>>>>>>>>>>>> moments thought.
>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>> problem yet,
>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>
>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>> continuous.
>>>>>>>>>>
>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>> different?)
>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>> I contributed a
>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>> nice, I admit.
>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>> are evaluated
>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>
>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>> problem
>>>>>>>>>>> is that
>>>>>>>>>>>          store
>>>>>>>>>>>          sync
>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>> only
>>>>>>>>>>>          sync
>>>>>>>>>>>          load
>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>> pass that test.
>>>>>>>>>>
>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>> term and
>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>          The JMM is fine. And
>>>>>>>>>>>          store
>>>>>>>>>>>          MemBarVolatile
>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>> that
>>>>>>>>>>> do what is required.
>>>>>>>>>>>
>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>
>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>> initializing
>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>> Shipilev
>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>            LongVolatileTest
>>>>>>>>>>>>            AtomicIntegerInitialValueTest
>>>>>>>>>>>> will fail.
>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>
>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>> volatiles do
>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>> that
>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>> Aleksey
>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>
>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>> don't
>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>
>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>> account
>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>> different platforms
>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>> An example:
>>>>>>>>>>>>           MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>           MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>> this:
>>>>>>>>>>>>           MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>           MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>            MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>           MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>> can not implement
>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>
>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>> issue.
>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>> read
>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>
>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>> independent?
>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>
>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>> few
>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>> will
>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>> moment. The
>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>> requirements for
>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>> are not
>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>> store
>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>> of the
>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>> software
>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>> don't have
>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>
>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>> I will
>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>> it might
>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>> them).
>>>>>>>>>>>>
>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>> can
>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>> way :)
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>
>>>>>>>>>>>>          From what I understand what we see here is an attempt to
>>>>>>>>>>>> fix an
>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>> IRIW
>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>> doing the
>>>>>>>>>>>> load.
>>>>>>>>>>>>
>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>> would be
>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>> performance
>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>> that
>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>> this is
>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>> with the
>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>> the
>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>> properties
>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>> on a
>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>> reduce
>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>
>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>> under
>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>
>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>> current
>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>> is set
>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>
>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>
>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>> Java
>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>> explicitly
>>>>>>>>>>>> like this.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>> there
>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>> defines?
>>>>>>>>>>>>>          From what I understand our ppc port is also affected.
>>>>>>>>>>>>> David?
>>>>>>>>>>>>
>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>> specific which
>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>             if (is_vol) {
>>>>>>>>>>>>>               // See comment in do_get_xxx().
>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>> #else
>>>>>>>>>>>>>               if (is_field) {
>>>>>>>>>>>>>                 // Add MemBarRelease for constructors which write
>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>                 set_wrote_volatile(true);
>>>>>>>>>>>>>               }
>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>             }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>            __________    __________    __________    __________
>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>                           read(y)                     read(x)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>

From harold.seigel at oracle.com  Tue Jan 21 05:48:08 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 21 Jan 2014 08:48:08 -0500
Subject: RFR(S) 8030955: assert(_prologue != NULL) failed: prologue pointer
	must be initialized
In-Reply-To: <52D9AAE2.6090508@oracle.com>
References: <52D98494.2060100@oracle.com> <52D98B35.7040507@oracle.com>
	<52D9AAE2.6090508@oracle.com>
Message-ID: <52DE7A98.2010504@oracle.com>

Hi Coleen,

Thanks for the review.  I already removed the useless import 
statements.  So, I plan to leave them out.

Harold

On 1/17/2014 5:12 PM, Coleen Phillimore wrote:
> On 1/17/2014 2:57 PM, Calvin Cheung wrote:
>> Harold,
>>
>> The backport looks good.
>> One nit: I don't think you need the following import in the test case.
>> 32 import java.io.File;
>> 33 import java.util.Map;
>
> The backport looks good.   If the jdk9 test case has these imports, I 
> think you should leave them in the backport for consistency.
> Coleen
>
>>
>> Calvin
>>
>> On 1/17/2014 11:29 AM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this backport to JDK8u of the JDK 9 hotspot fix for 
>>> bug JDK-8030955.  This backport was tested with the jtreg hotspot 
>>> tests, ute quick tests, and the accompanying test.
>>>
>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8030955
>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8030955_8u/
>>>
>>> Thanks! Harold
>>
>


From henry.jen at oracle.com  Tue Jan 21 10:20:22 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 21 Jan 2014 10:20:22 -0800
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DD1C8A.4020502@oracle.com>
References: <52D98C9E.8070906@oracle.com> <52DD1C8A.4020502@oracle.com>
Message-ID: <52DEBA66.3030709@oracle.com>


On 01/20/2014 04:54 AM, Erik Joelsson wrote:
> I suggested the change back then and even though I had to think for a
> while to figure out what it did, it still looks correct.
>
> As for pushing, as a jdk9 committer, it is my understanding that you are
> allowed to push it yourself to Hotspot, as long as you use Jprt and push
> to the correct group repo.
>

Cool, I will do that and push to jdk9/dev/hotspot.

Cheers,
Henry

> /Erik
>
> On 2014-01-17 21:03, Henry Jen wrote:
>> Hi,
>>
>> This is a follow up on an issue first reported on Nov. 2, the fix had
>> been discussed at that time[1] and works for me.
>>
>> The issue is that the sed command in adjust-mflags.sh trying to
>> isolate -j switch failed to deal with new MFLAGS format spitted out by
>> gmake 4, where the -I<path> without a space, and so if the path
>> contains 'j', the script is confused.
>>
>> Here is a webrev for JDK9,
>> http://cr.openjdk.java.net/~henryjen/jdk9/8028407/0/
>>
>> Would like to have a sponsor review and push the change, I am tired of
>> patching this. :)
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011692.html
>>
>>
>> Cheers,
>> Henry
>

From vladimir.kozlov at oracle.com  Tue Jan 21 12:00:18 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 21 Jan 2014 12:00:18 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<5295DD0B.3030604@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>
	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>
	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
	<52DE5FB0.5000808@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DED1D2.1070203@oracle.com>

Thanks. I am pushing it.

Vladimir

On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
> Sorry, I missed that.  fixed.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 21. Januar 2014 12:53
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Thanks Goetz!
>
> This typo still exists:
>
> +   bool          _wrote_volatile;     // Did we write a final field?
>
> s/final/volatile/
>
> Otherwise no further comments from me.
>
> David
>
> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I made a new webrev
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>> differing from
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>> only in the comments.
>>
>> I removed
>> // Support ordering of "Independent Reads of Independent Writes".
>> everywhere, and edited the comments in the globalDefinition*.hpp
>> files.
>>
>> Best regards,
>>     Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 21. Januar 2014 05:55
>> To: Lindenmaier, Goetz; Vladimir Kozlov
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz,
>>
>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I tried to come up with a webrev that implements the change as proposed in
>>> your mails:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>
>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>
>> Given the flag name the commentary eg:
>>
>> +       // Support ordering of "Independent Reads of Independent Writes".
>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>
>> seems somewhat redundant.
>>
>>> I left the definition and handling of _wrote_volatile in the code, without
>>> any protection.
>>
>> +   bool          _wrote_volatile;     // Did we write a final field?
>>
>> s/final/volatile
>>
>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>> and put it on one line.
>>>
>>> I removed the comment in library_call.cpp.
>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>> from the comments as it's PPC specific.
>>
>> I think the primary IRIW comment/explanation should go in
>> globalDefinitions.hpp where
>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>
>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>> issues in C1 if nobody did it by then.
>>
>> I've filed:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>
>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>> platforms"
>>
>> to cover this task, as it may be needed sooner rather than later.
>>
>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>
>> Ok.
>>
>> Thanks,
>> David
>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>> To: Vladimir Kozlov
>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>> parse.hpp.
>>>>>>
>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>> which could be checked in all places instead of #ifdef:
>>>>>
>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>> have this as a build-time construct rather than a
>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>> use it.
>>>>
>>>> Any decent C++ compiler will optimize expressions with such constants
>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>
>>> If you insist then we may as well do it all the same way. Better to be
>>> consistent.
>>>
>>> My apologies Goetz for wasting your time going back and forth on this.
>>>
>>> That aside I have a further concern with this IRIW support - it is
>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>> this is going on then we (which probably means the Oracle 'we') need to
>>> add the missing C1 code.
>>>
>>> David
>>> -----
>>>
>>>> Vladimir
>>>>
>>>>>
>>>>> David
>>>>>
>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>> #else
>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>> #endif
>>>>>>
>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>
>>>>>> and then:
>>>>>>
>>>>>>      #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>        oop p = JNIHandles::resolve(obj); \
>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>> OrderAccess::fence(); \
>>>>>>        volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>
>>>>>> And:
>>>>>>
>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>> field->is_volatile()) {
>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>> +  }
>>>>>>
>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>
>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>
>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>> method()->is_initializer()) )) {
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> I updated the webrev:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>
>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>       reflect the new flagging.  Also I mention that we support the
>>>>>>>>       volatile constructor issue, but that it's not standard.
>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>       I also think it's better to separate these this way.
>>>>>>>
>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>> please.
>>>>>>>
>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>> ppc specific stuff in a shared file:
>>>>>>>
>>>>>>>         if (is_volatile) {
>>>>>>> !     if (!is_store) {
>>>>>>>             insert_mem_bar(Op_MemBarAcquire);
>>>>>>> !     } else {
>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>             insert_mem_bar(Op_MemBarVolatile);
>>>>>>> + #endif
>>>>>>> +     }
>>>>>>>
>>>>>>> I don't think the comment is needed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Thanks for your comments!
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>
>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>> specifically it is
>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>> Seems
>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>
>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>> discussed
>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>> PPC64 porters.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>> this version.
>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>> To: David Holmes
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>> not
>>>>>>>>>> required to pass.
>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>> worked
>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>> it by
>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>> part is
>>>>>>>>> not that performance relevant.
>>>>>>>>>
>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>> think
>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz
>>>>>>>>>
>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>> emails.
>>>>>>>>>
>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>> settled.
>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>
>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>> The change is about IRIW.
>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>
>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>> But I'm
>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>
>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>> stores.
>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>> constructor tests.
>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>> after stores
>>>>>>>>>>            to pass the volatile constructor tests.
>>>>>>>>>
>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>> were not
>>>>>>>>> required to pass.
>>>>>>>>>
>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>> order
>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>> The only instruction
>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>> therefore the
>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>> proper representation
>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>> it's pointless
>>>>>>>>>> anyways.
>>>>>>>>>>
>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>         OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>
>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>> think
>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>> Or also
>>>>>>>>>>          OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>          VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> TL;DR version:
>>>>>>>>>>
>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>> constructor-barrier
>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>> *may*
>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>> ensure
>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>> invalid
>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>> need it
>>>>>>>>>> due to other factors).
>>>>>>>>>>
>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>> term :)
>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>
>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>> visible to
>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>> architectures
>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>
>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>> ARM and
>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>
>>>>>>>>>>        > The fixes for the constructor issue are only needed because we
>>>>>>>>>>        > remove the sync instruction from behind stores
>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>        > and place it before loads.
>>>>>>>>>>
>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>> after
>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>> same
>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>> load -
>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>> clearer.
>>>>>>>>>>
>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>> implemented as
>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>> hooks
>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>
>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>> this
>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>
>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>           OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>           VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>> or
>>>>>>>>>>>          OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>
>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>
>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>> store
>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @David
>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>> continuous.
>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>> issue.
>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>> you
>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>> solution,
>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>> issues.
>>>>>>>>>>>
>>>>>>>>>>> @David
>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>> and
>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>> ARM and
>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>
>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>> used 'read'
>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>> above).
>>>>>>>>>>>
>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>> processors
>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>
>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>
>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>> a few
>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>> problem yet,
>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>
>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>> continuous.
>>>>>>>>>>>
>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>> different?)
>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>> I contributed a
>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>> are evaluated
>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>> problem
>>>>>>>>>>>> is that
>>>>>>>>>>>>           store
>>>>>>>>>>>>           sync
>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>> only
>>>>>>>>>>>>           sync
>>>>>>>>>>>>           load
>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>> pass that test.
>>>>>>>>>>>
>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>> term and
>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>           The JMM is fine. And
>>>>>>>>>>>>           store
>>>>>>>>>>>>           MemBarVolatile
>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>> that
>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>
>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>> initializing
>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>             LongVolatileTest
>>>>>>>>>>>>>             AtomicIntegerInitialValueTest
>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>
>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>> volatiles do
>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>> that
>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>> Aleksey
>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>
>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>> don't
>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>> account
>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>            MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>            MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>> this:
>>>>>>>>>>>>>            MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>            MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>             MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>            MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>> read
>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>> independent?
>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>
>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>> few
>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>> will
>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>> moment. The
>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>> requirements for
>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>> are not
>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>> store
>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>> of the
>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>> software
>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>> don't have
>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>> I will
>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>> it might
>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>> them).
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>> can
>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           From what I understand what we see here is an attempt to
>>>>>>>>>>>>> fix an
>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>> doing the
>>>>>>>>>>>>> load.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>> would be
>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>> performance
>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>> that
>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>> this is
>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>> the
>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>> properties
>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>> on a
>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>> reduce
>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>> under
>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>> Java
>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>> there
>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>           From what I understand our ppc port is also affected.
>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>              if (is_vol) {
>>>>>>>>>>>>>>                // See comment in do_get_xxx().
>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>                insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>                if (is_field) {
>>>>>>>>>>>>>>                  // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>                  set_wrote_volatile(true);
>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>              }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>             __________    __________    __________    __________
>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>              write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>                            read(y)                     read(x)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>>

From alejandro.murillo at oracle.com  Tue Jan 21 16:34:42 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 21 Jan 2014 17:34:42 -0700
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DEBA66.3030709@oracle.com>
References: <52D98C9E.8070906@oracle.com> <52DD1C8A.4020502@oracle.com>
	<52DEBA66.3030709@oracle.com>
Message-ID: <52DF1222.8000602@oracle.com>


On 1/21/2014 11:20 AM, Henry Jen wrote:
>
> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>> I suggested the change back then and even though I had to think for a
>> while to figure out what it did, it still looks correct.
>>
>> As for pushing, as a jdk9 committer, it is my understanding that you are
>> allowed to push it yourself to Hotspot, as long as you use Jprt and push
>> to the correct group repo.
>>
>
> Cool, I will do that and push to jdk9/dev/hotspot.
you should push this to a hotspot group repo.
I suggest you push it to: jdk9/hs-rt/hotspot

thanks
Alejandro
>
> Cheers,
> Henry
>
>> /Erik
>>
>> On 2014-01-17 21:03, Henry Jen wrote:
>>> Hi,
>>>
>>> This is a follow up on an issue first reported on Nov. 2, the fix had
>>> been discussed at that time[1] and works for me.
>>>
>>> The issue is that the sed command in adjust-mflags.sh trying to
>>> isolate -j switch failed to deal with new MFLAGS format spitted out by
>>> gmake 4, where the -I<path> without a space, and so if the path
>>> contains 'j', the script is confused.
>>>
>>> Here is a webrev for JDK9,
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8028407/0/
>>>
>>> Would like to have a sponsor review and push the change, I am tired of
>>> patching this. :)
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011692.html 
>>>
>>>
>>>
>>> Cheers,
>>> Henry
>>

-- 
Alejandro


From david.holmes at oracle.com  Tue Jan 21 17:49:18 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Jan 2014 11:49:18 +1000
Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in
	need_compact3 test group
In-Reply-To: <52DE7061.2050607@oracle.com>
References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com>
	<52DE40D9.6090604@oracle.com> <52DE6030.4090500@oracle.com>
	<52DE7061.2050607@oracle.com>
Message-ID: <52DF239E.1010507@oracle.com>

On 21/01/2014 11:04 PM, Igor Ignatyev wrote:
> I will file an RFE to get rid of JMX in CompilerWhiteBoxTest.

Thanks. Will need to remember to revert this change then too.

> Can I count you as an reviewer?

Yes - sorry that wasn't clear.

Thanks,
David

> Igor
>
> On 01/21/2014 03:55 PM, David Holmes wrote:
>> On 21/01/2014 7:41 PM, Igor Ignatyev wrote:
>>> Hi David,
>>>
>>> Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest,
>>> super-class of these tests, uses it.
>>
>> I see. That is unfortunate as it constrains the test environment for
>> users of the Whitebox API even if they don't need the JMX part directly.
>> Whomever owns this should see if they can rectify this some how.
>>
>> Thanks,
>> David
>>
>>> Igor
>>>
>>> On 01/21/2014 07:01 AM, David Holmes wrote:
>>>> Hi Igor,
>>>>
>>>> On 20/01/2014 10:27 PM, Igor Ignatyev wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review patch:
>>>>>
>>>>> Problem:
>>>>> tests 'compiler/tiered/NonTieredLevelsTest.java' and
>>>>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group
>>>>
>>>> I don't see any direct JMX use in those tests. Is it coming in via the
>>>> Whitebox API? That would be unfortunate.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Fix:
>>>>> tests are added into 'need_compact3'
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482

From henry.jen at oracle.com  Tue Jan 21 20:47:18 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 21 Jan 2014 20:47:18 -0800
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DF1222.8000602@oracle.com>
References: <52D98C9E.8070906@oracle.com>
	<52DD1C8A.4020502@oracle.com>	<52DEBA66.3030709@oracle.com>
	<52DF1222.8000602@oracle.com>
Message-ID: <52DF4D56.6070107@oracle.com>

On 01/21/2014 04:34 PM, Alejandro E Murillo wrote:
>
> On 1/21/2014 11:20 AM, Henry Jen wrote:
>>
>> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>>> I suggested the change back then and even though I had to think for a
>>> while to figure out what it did, it still looks correct.
>>>
>>> As for pushing, as a jdk9 committer, it is my understanding that you are
>>> allowed to push it yourself to Hotspot, as long as you use Jprt and push
>>> to the correct group repo.
>>>
>>
>> Cool, I will do that and push to jdk9/dev/hotspot.
> you should push this to a hotspot group repo.
> I suggest you push it to: jdk9/hs-rt/hotspot
>

Sorry I had pushed this before read this email, I assume the propagation 
will happen eventually.

Also I think it won't hurt if anyone in hotspot group would like to 
cherry-pick that particular changeset.

http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8d4d0db1f06

Apologize if this cause any inconvinience.

Cheers,
Henry

From david.holmes at oracle.com  Tue Jan 21 22:48:48 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Jan 2014 16:48:48 +1000
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DF4D56.6070107@oracle.com>
References: <52D98C9E.8070906@oracle.com>	<52DD1C8A.4020502@oracle.com>	<52DEBA66.3030709@oracle.com>	<52DF1222.8000602@oracle.com>
	<52DF4D56.6070107@oracle.com>
Message-ID: <52DF69D0.4000307@oracle.com>

On 22/01/2014 2:47 PM, Henry Jen wrote:
> On 01/21/2014 04:34 PM, Alejandro E Murillo wrote:
>>
>> On 1/21/2014 11:20 AM, Henry Jen wrote:
>>>
>>> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>>>> I suggested the change back then and even though I had to think for a
>>>> while to figure out what it did, it still looks correct.
>>>>
>>>> As for pushing, as a jdk9 committer, it is my understanding that you
>>>> are
>>>> allowed to push it yourself to Hotspot, as long as you use Jprt and
>>>> push to the correct group repo.
>>>>
>>>
>>> Cool, I will do that and push to jdk9/dev/hotspot.
>> you should push this to a hotspot group repo.
>> I suggest you push it to: jdk9/hs-rt/hotspot
>>
>
> Sorry I had pushed this before read this email, I assume the propagation
> will happen eventually.
>
> Also I think it won't hurt if anyone in hotspot group would like to
> cherry-pick that particular changeset.
>
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8d4d0db1f06
>
> Apologize if this cause any inconvinience.

Although the new repo layout seems to allow for this (pushing straight 
to jdk9/dev/hotspot) I haven't seen anything clarifying what testing 
will happen to any such pushes :(

David

> Cheers,
> Henry

From alejandro.murillo at oracle.com  Tue Jan 21 22:55:43 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 21 Jan 2014 23:55:43 -0700
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DF4D56.6070107@oracle.com>
References: <52D98C9E.8070906@oracle.com>	<52DD1C8A.4020502@oracle.com>	<52DEBA66.3030709@oracle.com>	<52DF1222.8000602@oracle.com>
	<52DF4D56.6070107@oracle.com>
Message-ID: <52DF6B6F.7000708@oracle.com>


On 1/21/2014 9:47 PM, Henry Jen wrote:
> On 01/21/2014 04:34 PM, Alejandro E Murillo wrote:
>>
>> On 1/21/2014 11:20 AM, Henry Jen wrote:
>>>
>>> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>>>> I suggested the change back then and even though I had to think for a
>>>> while to figure out what it did, it still looks correct.
>>>>
>>>> As for pushing, as a jdk9 committer, it is my understanding that 
>>>> you are
>>>> allowed to push it yourself to Hotspot, as long as you use Jprt and 
>>>> push
>>>> to the correct group repo.
>>>>
>>>
>>> Cool, I will do that and push to jdk9/dev/hotspot.
>> you should push this to a hotspot group repo.
>> I suggest you push it to: jdk9/hs-rt/hotspot
>>
>
> Sorry I had pushed this before read this email, I assume the 
> propagation will happen eventually.
>
> Also I think it won't hurt if anyone in hotspot group would like to 
> cherry-pick that particular changeset.
>
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8d4d0db1f06
>
> Apologize if this cause any inconvinience.
>
> Cheers,
> Henry
Erik's email, that you replied, indicated that this should have
been pushed to the right repo and using JPRT.
doesn't look like you used JPRT to push this change either,
Hotspot changes must be pushed using JPRT.

the propagation will happen, but the problem is that
it won't get proper nightly or PIT testing on that repo before
going to master.

If you didn't push using JPRT, then please run a non pushing hotspot
job to verify all the bundles, including embedded ones, are building
without problem.

Thanks

-- 
Alejandro


From david.holmes at oracle.com  Tue Jan 21 23:07:07 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Jan 2014 17:07:07 +1000
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DF6B6F.7000708@oracle.com>
References: <52D98C9E.8070906@oracle.com>	<52DD1C8A.4020502@oracle.com>	<52DEBA66.3030709@oracle.com>	<52DF1222.8000602@oracle.com>	<52DF4D56.6070107@oracle.com>
	<52DF6B6F.7000708@oracle.com>
Message-ID: <52DF6E1B.1060903@oracle.com>

Henry,

hotspot changes also traditionally require two reviewers, unlike 
core-libs. Though given the rules are now set by the jdk9 project it 
isn't clear how that can be enforced :(

David

On 22/01/2014 4:55 PM, Alejandro E Murillo wrote:
>
> On 1/21/2014 9:47 PM, Henry Jen wrote:
>> On 01/21/2014 04:34 PM, Alejandro E Murillo wrote:
>>>
>>> On 1/21/2014 11:20 AM, Henry Jen wrote:
>>>>
>>>> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>>>>> I suggested the change back then and even though I had to think for a
>>>>> while to figure out what it did, it still looks correct.
>>>>>
>>>>> As for pushing, as a jdk9 committer, it is my understanding that
>>>>> you are
>>>>> allowed to push it yourself to Hotspot, as long as you use Jprt and
>>>>> push
>>>>> to the correct group repo.
>>>>>
>>>>
>>>> Cool, I will do that and push to jdk9/dev/hotspot.
>>> you should push this to a hotspot group repo.
>>> I suggest you push it to: jdk9/hs-rt/hotspot
>>>
>>
>> Sorry I had pushed this before read this email, I assume the
>> propagation will happen eventually.
>>
>> Also I think it won't hurt if anyone in hotspot group would like to
>> cherry-pick that particular changeset.
>>
>> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8d4d0db1f06
>>
>> Apologize if this cause any inconvinience.
>>
>> Cheers,
>> Henry
> Erik's email, that you replied, indicated that this should have
> been pushed to the right repo and using JPRT.
> doesn't look like you used JPRT to push this change either,
> Hotspot changes must be pushed using JPRT.
>
> the propagation will happen, but the problem is that
> it won't get proper nightly or PIT testing on that repo before
> going to master.
>
> If you didn't push using JPRT, then please run a non pushing hotspot
> job to verify all the bundles, including embedded ones, are building
> without problem.
>
> Thanks
>

From erik.joelsson at oracle.com  Wed Jan 22 00:48:10 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 22 Jan 2014 09:48:10 +0100
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DEBA66.3030709@oracle.com>
References: <52D98C9E.8070906@oracle.com> <52DD1C8A.4020502@oracle.com>
	<52DEBA66.3030709@oracle.com>
Message-ID: <52DF85CA.7020102@oracle.com>

I'm pretty sure that is not the correct group repo. My guess would be 
jdk9/hs-rt/hotspot, but if in doubt, please talk to a Hotspot engineer.

/Erik

On 2014-01-21 19:20, Henry Jen wrote:
>
> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>> I suggested the change back then and even though I had to think for a
>> while to figure out what it did, it still looks correct.
>>
>> As for pushing, as a jdk9 committer, it is my understanding that you are
>> allowed to push it yourself to Hotspot, as long as you use Jprt and push
>> to the correct group repo.
>>
>
> Cool, I will do that and push to jdk9/dev/hotspot.
>
> Cheers,
> Henry
>
>> /Erik
>>
>> On 2014-01-17 21:03, Henry Jen wrote:
>>> Hi,
>>>
>>> This is a follow up on an issue first reported on Nov. 2, the fix had
>>> been discussed at that time[1] and works for me.
>>>
>>> The issue is that the sed command in adjust-mflags.sh trying to
>>> isolate -j switch failed to deal with new MFLAGS format spitted out by
>>> gmake 4, where the -I<path> without a space, and so if the path
>>> contains 'j', the script is confused.
>>>
>>> Here is a webrev for JDK9,
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8028407/0/
>>>
>>> Would like to have a sponsor review and push the change, I am tired of
>>> patching this. :)
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011692.html 
>>>
>>>
>>>
>>> Cheers,
>>> Henry
>>


From goetz.lindenmaier at sap.com  Wed Jan 22 01:20:47 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Jan 2014 09:20:47 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads	of Independent Writes
In-Reply-To: <52DED1D2.1070203@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<5295DD0B.3030604@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
	<52DE5FB0.5000808@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
	<52DED1D2.1070203@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>

Hi Vladimir,

Thanks for testing and pushing!

Will you push this also to stage?  I assume we can handle this
as the other three hotspot changes, without a new bug-id?

Also, when do you think we (you unfortunately) should update 
the repos again?  Stage-9 maybe after Volkers last change is submitted?

Best regards,
  Goetz



-----Original Message-----
From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Dienstag, 21. Januar 2014 21:00
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Thanks. I am pushing it.

Vladimir

On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
> Sorry, I missed that.  fixed.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 21. Januar 2014 12:53
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Thanks Goetz!
>
> This typo still exists:
>
> +   bool          _wrote_volatile;     // Did we write a final field?
>
> s/final/volatile/
>
> Otherwise no further comments from me.
>
> David
>
> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I made a new webrev
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>> differing from
>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>> only in the comments.
>>
>> I removed
>> // Support ordering of "Independent Reads of Independent Writes".
>> everywhere, and edited the comments in the globalDefinition*.hpp
>> files.
>>
>> Best regards,
>>     Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 21. Januar 2014 05:55
>> To: Lindenmaier, Goetz; Vladimir Kozlov
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz,
>>
>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I tried to come up with a webrev that implements the change as proposed in
>>> your mails:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>
>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>
>> Given the flag name the commentary eg:
>>
>> +       // Support ordering of "Independent Reads of Independent Writes".
>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>
>> seems somewhat redundant.
>>
>>> I left the definition and handling of _wrote_volatile in the code, without
>>> any protection.
>>
>> +   bool          _wrote_volatile;     // Did we write a final field?
>>
>> s/final/volatile
>>
>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>> and put it on one line.
>>>
>>> I removed the comment in library_call.cpp.
>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>> from the comments as it's PPC specific.
>>
>> I think the primary IRIW comment/explanation should go in
>> globalDefinitions.hpp where
>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>
>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>> issues in C1 if nobody did it by then.
>>
>> I've filed:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>
>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>> platforms"
>>
>> to cover this task, as it may be needed sooner rather than later.
>>
>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>
>> Ok.
>>
>> Thanks,
>> David
>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>> To: Vladimir Kozlov
>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>> parse.hpp.
>>>>>>
>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>> which could be checked in all places instead of #ifdef:
>>>>>
>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>> have this as a build-time construct rather than a
>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>> use it.
>>>>
>>>> Any decent C++ compiler will optimize expressions with such constants
>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>
>>> If you insist then we may as well do it all the same way. Better to be
>>> consistent.
>>>
>>> My apologies Goetz for wasting your time going back and forth on this.
>>>
>>> That aside I have a further concern with this IRIW support - it is
>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>> this is going on then we (which probably means the Oracle 'we') need to
>>> add the missing C1 code.
>>>
>>> David
>>> -----
>>>
>>>> Vladimir
>>>>
>>>>>
>>>>> David
>>>>>
>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>> #else
>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>> #endif
>>>>>>
>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>
>>>>>> and then:
>>>>>>
>>>>>>      #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>        oop p = JNIHandles::resolve(obj); \
>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>> OrderAccess::fence(); \
>>>>>>        volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>
>>>>>> And:
>>>>>>
>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>> field->is_volatile()) {
>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>> +  }
>>>>>>
>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>
>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>
>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>> method()->is_initializer()) )) {
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> I updated the webrev:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>
>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>       reflect the new flagging.  Also I mention that we support the
>>>>>>>>       volatile constructor issue, but that it's not standard.
>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>       I also think it's better to separate these this way.
>>>>>>>
>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>> please.
>>>>>>>
>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>> ppc specific stuff in a shared file:
>>>>>>>
>>>>>>>         if (is_volatile) {
>>>>>>> !     if (!is_store) {
>>>>>>>             insert_mem_bar(Op_MemBarAcquire);
>>>>>>> !     } else {
>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>             insert_mem_bar(Op_MemBarVolatile);
>>>>>>> + #endif
>>>>>>> +     }
>>>>>>>
>>>>>>> I don't think the comment is needed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Thanks for your comments!
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>
>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>> specifically it is
>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>> Seems
>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>
>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>> discussed
>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>> PPC64 porters.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>> this version.
>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>> To: David Holmes
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>> not
>>>>>>>>>> required to pass.
>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>> worked
>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>> it by
>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>> part is
>>>>>>>>> not that performance relevant.
>>>>>>>>>
>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>> think
>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz
>>>>>>>>>
>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>> emails.
>>>>>>>>>
>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>> settled.
>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>
>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>> The change is about IRIW.
>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>
>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>> But I'm
>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>
>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>> stores.
>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>> constructor tests.
>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>> after stores
>>>>>>>>>>            to pass the volatile constructor tests.
>>>>>>>>>
>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>> were not
>>>>>>>>> required to pass.
>>>>>>>>>
>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>> order
>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>> The only instruction
>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>> therefore the
>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>> proper representation
>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>> it's pointless
>>>>>>>>>> anyways.
>>>>>>>>>>
>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>         OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>
>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>> think
>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>> Or also
>>>>>>>>>>          OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>          VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> TL;DR version:
>>>>>>>>>>
>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>> constructor-barrier
>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>> *may*
>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>> ensure
>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>> invalid
>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>> need it
>>>>>>>>>> due to other factors).
>>>>>>>>>>
>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>> term :)
>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>
>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>> visible to
>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>> architectures
>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>
>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>> ARM and
>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>
>>>>>>>>>>        > The fixes for the constructor issue are only needed because we
>>>>>>>>>>        > remove the sync instruction from behind stores
>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>        > and place it before loads.
>>>>>>>>>>
>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>> after
>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>> same
>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>> load -
>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>> clearer.
>>>>>>>>>>
>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>> implemented as
>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>> hooks
>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>
>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>> this
>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>
>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>           OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>           VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>> or
>>>>>>>>>>>          OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>
>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>
>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>> store
>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @David
>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>> continuous.
>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>> issue.
>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>> you
>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>> solution,
>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>> issues.
>>>>>>>>>>>
>>>>>>>>>>> @David
>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>> and
>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>> ARM and
>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>
>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>> used 'read'
>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>> above).
>>>>>>>>>>>
>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>> processors
>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>
>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>
>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>> a few
>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>> problem yet,
>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>
>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>> continuous.
>>>>>>>>>>>
>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>> different?)
>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>> I contributed a
>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>> are evaluated
>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>> problem
>>>>>>>>>>>> is that
>>>>>>>>>>>>           store
>>>>>>>>>>>>           sync
>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>> only
>>>>>>>>>>>>           sync
>>>>>>>>>>>>           load
>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>> pass that test.
>>>>>>>>>>>
>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>> term and
>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>           The JMM is fine. And
>>>>>>>>>>>>           store
>>>>>>>>>>>>           MemBarVolatile
>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>> that
>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>
>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>> initializing
>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>             LongVolatileTest
>>>>>>>>>>>>>             AtomicIntegerInitialValueTest
>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>
>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>> volatiles do
>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>> that
>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>> Aleksey
>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>
>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>> don't
>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>> account
>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>            MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>            MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>> this:
>>>>>>>>>>>>>            MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>            MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>             MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>            MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>> read
>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>> independent?
>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>
>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>> few
>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>> will
>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>> moment. The
>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>> requirements for
>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>> are not
>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>> store
>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>> of the
>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>> software
>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>> don't have
>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>> I will
>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>> it might
>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>> them).
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>> can
>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           From what I understand what we see here is an attempt to
>>>>>>>>>>>>> fix an
>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>> doing the
>>>>>>>>>>>>> load.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>> would be
>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>> performance
>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>> that
>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>> this is
>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>> the
>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>> properties
>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>> on a
>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>> reduce
>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>> under
>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>> Java
>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>> there
>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>           From what I understand our ppc port is also affected.
>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>              if (is_vol) {
>>>>>>>>>>>>>>                // See comment in do_get_xxx().
>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>                insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>                if (is_field) {
>>>>>>>>>>>>>>                  // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>                  set_wrote_volatile(true);
>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>              }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>             __________    __________    __________    __________
>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>              write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>                            read(y)                     read(x)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>>

From goetz.lindenmaier at sap.com  Wed Jan 22 06:01:14 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Jan 2014 14:01:14 +0000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <52DDE01D.1060605@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>
	<52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com>
	<52D821CB.6020207@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>
	<52DC8DA9.2010106@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap>
	<52DDE01D.1060605@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F125@DEWDFEMB12A.global.corp.sap>

Hi,

thanks for the hint to this paper, David!  
We modified the known read-after-write test to use the serialization page
mechanism, and reading that paper we were able to understand it is correct
on X86 / TSO.  Thanks to Andreas Schoesser for this.
http://cr.openjdk.java.net/~goetz/raw_serialization_page/raw_s11n_page.cpp

We ran the test on linux ppc and aix over the weekend, without failure.
This indicates the mechanism works there, too.
The test fails immediately if the "write" in the fast thread is omitted.
We also checked that both threads make considerable progress, and the
fast thread does not always trap.

Also, we looked at documentation about how mprotect etc should
be implemented on ppc.
A mprotect should do a tlbie, invidating the TLBs of all processors.
It also should do an eieio and a tlbsync
This assures the TLB of the "fast" process doing only the write is
invalidated before mprotect returns.  So the fast thread will 
experience a TLB-miss on the write.  We assume on the TLB-miss
some synchronization instruction is used, probably the ptesync.
This should assure the fast thread gets the new value even if the 
page is already writable again.
Unfortunately this is implemented in supervisor code, which is not 
available to us.

I'll add a patch that enables UseMembar in our VM to test the performance
impacts of that variant.
As I don't see a good reason this flag is product, I'll change it to 
debug for the test.  As you described, the flag should be set depending on 
whether the serialization page works.  So nowadays it serves as a platform 
configuration so I think debug is the better choice.
(Btw, you could move UsePPCLWSYNC into your globals_ppc.hpp with the new
platform-dependent flags.)

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 21. Januar 2014 03:49
To: Lindenmaier, Goetz; Vladimir Kozlov
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization

On 20/01/2014 11:41 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> I understand your arguments and basically agree with them.
> If the serialization page does not work on PPC, your solution
> 1) is best.
>
> But I'm not sure why there should be a link between TSO and whether
> the serialization page trick works.  Second depends, as you say,
> on the OS implementation.

My limited understanding is that on RMO-based systems the requirements for:

"Synchronization based on page-protections - mprotect()"

as described in:

http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt

may not always hold. Dave Dice would need to provide more details if needed.

Cheers,
David

> I would assume that the write to the serialization page causes
> the OS to generate a new TLB entry or the like, involving the
> use of a ptwsync instruction which would be fine.  But we are
> investigating this.
>
> We are also experimenting with a small regression test to find
> out whether the  serialization page ever fails.
>
> Best regards,
>    Goetz.
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Montag, 20. Januar 2014 03:45
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>
> On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I had a look at the first part of this issue: Whether StoreStore
>> is necessary in the interpreter.  Let's for now assume the serialization
>> page mechanism works on PPC.
>>
>> In the state transition leaving the VM state, which is executed in the
>> destructor, ThreadStateTransition::transition() is called, which executes
>>         if (UseMembar) {
>>           OrderAccess::fence();
>>         } else {
>>           os::write_memory_serialize_page(thread);
>>         }
>>
>> os:: write_memory_serialize_page() can not be considered a proper
>> MemBar, as it only serializes if another thread poisoned the page.
>> Thus it does not qualify to order the initialization and the publishing
>> of the object.
>>
>> You are right, if UseMembar is true, the StoreStore in the interpreter
>> is superfluous.  We could guard the StoreStores in the interpreter by
>> !UseMembar.
>
> My understanding, from our existing non-TSO system ports, is that the
> present assumption is that either:
>
> a) you have a TSO system, in which case you are probably using the
> serialization page, but you don't need any barrier to enforce ordering
> anyway; or
>
> b) you don't have a TSO system, you are using UseMembar==true and so you
> get a full fence inserted that enforces the ordering anyway.
>
> So the ordering requirements are satisfied by piggy-backing on the
> UseMembar setting that comes from the thread state transition code,
> which forms part of the "runtime entry" code. That's not to say that you
> will necessarily find this applied consistently in all places where it
> might be applied - nor will you necessarily find that this is common
> knowledge amongst VM engineers.
>
> Technically the storeStore barriers could be conditional on !UseMembar
> but that is redundant in the current usage.
>
>> But then again, one is to order the publishing of the thread states,
>> the other to enforce some Java semantics.  I don't know whether everybody
>> who changes in one place is aware of both issues.  But if you want to,
>> I'll add a !UseMembar in the interpreter.
>
> Here are my preferred options in order:
>
> 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers -
> rely on the piggy-backing effect.
>
> 2. Conditionalize the new storeStore barriers on !UseMembar. This
> unfortunately penalizes all platforms with a runtime check.
>
> 3. Add the storeStores unconditionally. This penalizes platforms that
> set UseMembar==true as we will now get two fences at runtime.
>
> I know we're talking about the interpreter here so performance is not
> exactly critical, but still ...
>
>> Maybe it would be a good idea
>> to document the double use in interfaceSupport.cpp, too.  And maybe
>> add an assertion of some kind.
>
> interfaceSupport doesn't know that other code piggy-backs on the fact
> state-transitions have full fences when UseMembar is true. If it is
> documented anywhere it should be in the interpreter (and any other
> places that makes the same assumption) - something like:
>
> // On non-TSO systems there can be additional ordering constraints
> // between Java-level actions (such as allocation and constructor
> // invocation) that in principle need explicit memory barriers.
> // However, on many non-TSO systems the thread-state transition logic
> // in the IRT_ENTRY code will insert a full fence due to the use of
> // UseMembar==true, which provides the necessary ordering guarantees.
>
>>
>> We're digging into the other issue currenty, whether the serialization page
>> works on ppc.  We understand your concerns and have no simple answer to
>> it right now.  At least, in our VM and in the port there are no known problems
>> with the state transitions.
>
> Even if the memory serialization page does not work, in a guaranteed
> sense, on PPC-AIX, it is extremely unlikely that testing would expose
> this. Also note that the memory serialization page behaviour is more a
> function of the OS - so it may be that AIX is different to linux in that
> regard.
>
> Cheers,
> David
> -----
>
>> Best regards,
>>     Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 16. Januar 2014 19:16
>> To: David Holmes; Lindenmaier, Goetz
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
>> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>>
>> Changes are in C++ Interpreter so it does not affect Oracle VM.
>> But David has point here. I would like to hear the explanation too.
>>
>> BTW, I see that for ppc64:
>>
>> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>>
>> as result write_memory_serialize_page() is used in
>> ThreadStateTransition::transition().
>>
>> Is it not enough on PPC64?
>>
>> Thanks,
>> Vladimir
>>
>> On 1/15/14 9:30 PM, David Holmes wrote:
>>> Can I get some response on this please - specifically the redundancy wrt
>>> IRT_ENTRY actions.
>>>
>>> Thanks,
>>> David
>>>
>>> On 20/12/2013 11:55 AM, David Holmes wrote:
>>>> Still catching up ...
>>>>
>>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> this change adds StoreStore barriers after object initialization and
>>>>> after constructor calls in the C++ interpreter.  This assures no
>>>>> uninitialized
>>>>> objects or final fields are visible.
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>>>
>>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>>>> thread state transitions that already include a full "fence" so the
>>>> storestore barriers are redundant in those cases.
>>>>
>>>> The fastpath _new storestore seems okay.
>>>>
>>>> I don't know how handle_return gets used to know if it is reasonable or
>>>> not.
>>>>
>>>> I was trying, unsuccessfully, to examine the same code in the
>>>> templateInterpreter to see how it handles these cases as it naturally
>>>> has the same object-initialization-safety requirements (though these can
>>>> be handled in a number of different ways other than an unconditional
>>>> storestore barrier at the end of the initialization and construction
>>>> phases.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Please review and test this change.
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>

From vladimir.kempik at oracle.com  Wed Jan 22 06:16:15 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Wed, 22 Jan 2014 18:16:15 +0400
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <5214D0AC.1000008@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
	<8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
	<5213E517.5000106@oracle.com> <5214991B.40107@oracle.com>
	<5214D0AC.1000008@oracle.com>
Message-ID: <52DFD2AF.4080607@oracle.com>

Hello everyone, do you think this patch could be applicable to jdk7 and 
jdk6 as well ?

There is little difference between jdk7 and jdk8 here, two asserts were 
removed from jdk8. asserts shouldn't be triggered in product build and 
patch wouldn't do any harm anyway.

   // if any one of the memory pool has undefined init_size or max_size,
   // set it to -1
   if (has_undefined_init_size) {
     total_init = (size_t)-1;
   }
   if (has_undefined_max_size) {
     total_max = (size_t)-1;
   }

   // In our current implementation, we make sure that all non-heap
   // pools have defined init and max sizes. Heap pools do not matter,
   // as we never use total_init and total_max for them.
   assert(heap || !has_undefined_init_size, "Undefined init size");
   assert(heap || !has_undefined_max_size,  "Undefined max size");

   MemoryUsage usage((heap ? InitialHeapSize : total_init),
                     total_used,
                     total_committed,
                     (heap ? Universe::heap()->max_capacity() : total_max));

Thanks Vladimir.

On 21.08.2013 18:37, Coleen Phillimore wrote:
>
> Looks good, thanks!
> Coleen
>
> On 8/21/2013 6:40 AM, Vladimir Kempik wrote:
>> Thanks everyone for comments.
>>
>> Here is updated webrev 
>> http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/
>>
>> Vladimir.
>> On 21.08.2013 1:52, Mandy Chung wrote:
>>>
>>> On 8/20/2013 5:38 AM, Staffan Larsen wrote:
>>>> That doesn't make a lot of sense to me. Why would a pool have 
>>>> undefined values?
>>>> The Metaspace pool has no max value (unless you specify 
>>>> -XX:MaxMetaspaceSize=), thus undefined.
>>>>
>>>>> If a subset of pools have undefined values why report completely 
>>>>> fallacious values of -1?
>>>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum 
>>>> memory size is undefined.
>>>
>>> Yes the spec allows implementation of memory pools with undefined 
>>> max.  "used" and "committed" must have a value and the "committed" 
>>> memory is guaranteed to be available for the VM to use.  "max" will 
>>> give an idea of the upper bound how much memory can be allocated 
>>> from it; however, there is no guarantee that amount of memory is 
>>> available for the VM.
>>>
>>>>> It also isn't clear how this relates to the "committed" value in 
>>>>> the failure. What gets reported now?
>>>> I guess there can still be a committed value even if we don't have 
>>>> a max value for how much we might commit in the future: used <= 
>>>> committed <= max.
>>>
>>> The MemoryUsage constructor throws IAE if committed > max if max is 
>>> defined.  Perhaps it would be better if max should be Long.MAX_VALUE 
>>> if undefined (a different issue than this bug).
>>>
>>> Mandy
>>>
>>>> /Staffan
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>
>>
>


From henry.jen at oracle.com  Wed Jan 22 08:28:57 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 22 Jan 2014 08:28:57 -0800
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DF6E1B.1060903@oracle.com>
References: <52D98C9E.8070906@oracle.com>	<52DD1C8A.4020502@oracle.com>	<52DEBA66.3030709@oracle.com>	<52DF1222.8000602@oracle.com>	<52DF4D56.6070107@oracle.com>
	<52DF6B6F.7000708@oracle.com> <52DF6E1B.1060903@oracle.com>
Message-ID: <52DFF1C9.10107@oracle.com>

I need to know better for hotspot process, which is why I was looking 
for a sponsor. Hopefully to adress the concerns,

- I had done jprt before the push
- This patch had been looked at in the past, hopefully I can count David 
as another reviewer as he understood this issue from last discussion.

Cheers,
Henry

On 01/21/2014 11:07 PM, David Holmes wrote:
> Henry,
>
> hotspot changes also traditionally require two reviewers, unlike
> core-libs. Though given the rules are now set by the jdk9 project it
> isn't clear how that can be enforced :(
>
> David
>
> On 22/01/2014 4:55 PM, Alejandro E Murillo wrote:
>>
>> On 1/21/2014 9:47 PM, Henry Jen wrote:
>>> On 01/21/2014 04:34 PM, Alejandro E Murillo wrote:
>>>>
>>>> On 1/21/2014 11:20 AM, Henry Jen wrote:
>>>>>
>>>>> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>>>>>> I suggested the change back then and even though I had to think for a
>>>>>> while to figure out what it did, it still looks correct.
>>>>>>
>>>>>> As for pushing, as a jdk9 committer, it is my understanding that
>>>>>> you are
>>>>>> allowed to push it yourself to Hotspot, as long as you use Jprt and
>>>>>> push
>>>>>> to the correct group repo.
>>>>>>
>>>>>
>>>>> Cool, I will do that and push to jdk9/dev/hotspot.
>>>> you should push this to a hotspot group repo.
>>>> I suggest you push it to: jdk9/hs-rt/hotspot
>>>>
>>>
>>> Sorry I had pushed this before read this email, I assume the
>>> propagation will happen eventually.
>>>
>>> Also I think it won't hurt if anyone in hotspot group would like to
>>> cherry-pick that particular changeset.
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8d4d0db1f06
>>>
>>> Apologize if this cause any inconvinience.
>>>
>>> Cheers,
>>> Henry
>> Erik's email, that you replied, indicated that this should have
>> been pushed to the right repo and using JPRT.
>> doesn't look like you used JPRT to push this change either,
>> Hotspot changes must be pushed using JPRT.
>>
>> the propagation will happen, but the problem is that
>> it won't get proper nightly or PIT testing on that repo before
>> going to master.
>>
>> If you didn't push using JPRT, then please run a non pushing hotspot
>> job to verify all the bundles, including embedded ones, are building
>> without problem.
>>
>> Thanks
>>

From vladimir.kozlov at oracle.com  Wed Jan 22 09:02:04 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Jan 2014 09:02:04 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<52968167.4050906@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>	<52DDFD9D.3050205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>	<52DE5FB0.5000808@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
	<52DED1D2.1070203@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>
Message-ID: <52DFF98C.8010001@oracle.com>

Hi Goetz

On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> Thanks for testing and pushing!
>
> Will you push this also to stage?  I assume we can handle this
> as the other three hotspot changes, without a new bug-id?

Yes, I will backport it.

What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581?
Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix 
from jdk9. Or I am mistaking?

>
> Also, when do you think we (you unfortunately) should update
> the repos again?  Stage-9 maybe after Volkers last change is submitted?

After I test and push 8031581 I will do sync with latest jdk9 sources (b01).
I will build bundles and give them to SQE for final testing.

Thanks,
Vladimir

>
> Best regards,
>    Goetz
>
>
>
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
> Sent: Dienstag, 21. Januar 2014 21:00
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Thanks. I am pushing it.
>
> Vladimir
>
> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>> Sorry, I missed that.  fixed.
>>
>> Best regards,
>>     Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 21. Januar 2014 12:53
>> To: Lindenmaier, Goetz; Vladimir Kozlov
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Thanks Goetz!
>>
>> This typo still exists:
>>
>> +   bool          _wrote_volatile;     // Did we write a final field?
>>
>> s/final/volatile/
>>
>> Otherwise no further comments from me.
>>
>> David
>>
>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I made a new webrev
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>> differing from
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>> only in the comments.
>>>
>>> I removed
>>> // Support ordering of "Independent Reads of Independent Writes".
>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>> files.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Dienstag, 21. Januar 2014 05:55
>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I tried to come up with a webrev that implements the change as proposed in
>>>> your mails:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>
>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>
>>> Given the flag name the commentary eg:
>>>
>>> +       // Support ordering of "Independent Reads of Independent Writes".
>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>
>>> seems somewhat redundant.
>>>
>>>> I left the definition and handling of _wrote_volatile in the code, without
>>>> any protection.
>>>
>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>
>>> s/final/volatile
>>>
>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>>> and put it on one line.
>>>>
>>>> I removed the comment in library_call.cpp.
>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>>> from the comments as it's PPC specific.
>>>
>>> I think the primary IRIW comment/explanation should go in
>>> globalDefinitions.hpp where
>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>
>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>>> issues in C1 if nobody did it by then.
>>>
>>> I've filed:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>
>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>>> platforms"
>>>
>>> to cover this task, as it may be needed sooner rather than later.
>>>
>>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>>
>>> Ok.
>>>
>>> Thanks,
>>> David
>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>> To: Vladimir Kozlov
>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>> parse.hpp.
>>>>>>>
>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>
>>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>>> have this as a build-time construct rather than a
>>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>>> use it.
>>>>>
>>>>> Any decent C++ compiler will optimize expressions with such constants
>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>>
>>>> If you insist then we may as well do it all the same way. Better to be
>>>> consistent.
>>>>
>>>> My apologies Goetz for wasting your time going back and forth on this.
>>>>
>>>> That aside I have a further concern with this IRIW support - it is
>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>>> this is going on then we (which probably means the Oracle 'we') need to
>>>> add the missing C1 code.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Vladimir
>>>>>
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>> #else
>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>> #endif
>>>>>>>
>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>
>>>>>>> and then:
>>>>>>>
>>>>>>>       #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>         oop p = JNIHandles::resolve(obj); \
>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>> OrderAccess::fence(); \
>>>>>>>         volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>
>>>>>>> And:
>>>>>>>
>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>> field->is_volatile()) {
>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>> +  }
>>>>>>>
>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>>
>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>
>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>> method()->is_initializer()) )) {
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> I updated the webrev:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>
>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>        reflect the new flagging.  Also I mention that we support the
>>>>>>>>>        volatile constructor issue, but that it's not standard.
>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>        I also think it's better to separate these this way.
>>>>>>>>
>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>> please.
>>>>>>>>
>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>
>>>>>>>>          if (is_volatile) {
>>>>>>>> !     if (!is_store) {
>>>>>>>>              insert_mem_bar(Op_MemBarAcquire);
>>>>>>>> !     } else {
>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>>              insert_mem_bar(Op_MemBarVolatile);
>>>>>>>> + #endif
>>>>>>>> +     }
>>>>>>>>
>>>>>>>> I don't think the comment is needed.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Thanks for your comments!
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>
>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>>> specifically it is
>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>>> Seems
>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>>
>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>> discussed
>>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>>> PPC64 porters.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>>> this version.
>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>> To: David Holmes
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>>> not
>>>>>>>>>>> required to pass.
>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>>> worked
>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>>> it by
>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>>> part is
>>>>>>>>>> not that performance relevant.
>>>>>>>>>>
>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>> think
>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz
>>>>>>>>>>
>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>>> emails.
>>>>>>>>>>
>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>>> settled.
>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>>
>>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>
>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>>> But I'm
>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>
>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>>> stores.
>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>> constructor tests.
>>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>>> after stores
>>>>>>>>>>>             to pass the volatile constructor tests.
>>>>>>>>>>
>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>> were not
>>>>>>>>>> required to pass.
>>>>>>>>>>
>>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>>> order
>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>>> The only instruction
>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>>> therefore the
>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>>> proper representation
>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>>> it's pointless
>>>>>>>>>>> anyways.
>>>>>>>>>>>
>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>          OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>
>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>> think
>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>>> Or also
>>>>>>>>>>>           OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>           VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>
>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>> constructor-barrier
>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>>> *may*
>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>>> ensure
>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>> invalid
>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>>> need it
>>>>>>>>>>> due to other factors).
>>>>>>>>>>>
>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>>> term :)
>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>
>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>> visible to
>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>> architectures
>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>
>>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>>> ARM and
>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>
>>>>>>>>>>>         > The fixes for the constructor issue are only needed because we
>>>>>>>>>>>         > remove the sync instruction from behind stores
>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>         > and place it before loads.
>>>>>>>>>>>
>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>>> after
>>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>>> same
>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>>> load -
>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>>> clearer.
>>>>>>>>>>>
>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>> implemented as
>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>>> hooks
>>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>
>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>>> this
>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>> or
>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>
>>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>
>>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>>> store
>>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> @David
>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>> continuous.
>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>>> issue.
>>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>>> you
>>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>>> solution,
>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>>> issues.
>>>>>>>>>>>>
>>>>>>>>>>>> @David
>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>>> and
>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>>> ARM and
>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>
>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>>> used 'read'
>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>>> above).
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>> processors
>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>
>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>
>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>
>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>> continuous.
>>>>>>>>>>>>
>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>> problem
>>>>>>>>>>>>> is that
>>>>>>>>>>>>>            store
>>>>>>>>>>>>>            sync
>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>> only
>>>>>>>>>>>>>            sync
>>>>>>>>>>>>>            load
>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>
>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>> term and
>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>            The JMM is fine. And
>>>>>>>>>>>>>            store
>>>>>>>>>>>>>            MemBarVolatile
>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>>> that
>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>              LongVolatileTest
>>>>>>>>>>>>>>              AtomicIntegerInitialValueTest
>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>>> that
>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>>> account
>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>             MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>>             MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>             MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>             MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>              MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>             MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>>> read
>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>>> few
>>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>>> will
>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>>> are not
>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>>> store
>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>>> of the
>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>>> software
>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>>> don't have
>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>>> I will
>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>            From what I understand what we see here is an attempt to
>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>>> under
>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>            From what I understand our ppc port is also affected.
>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>               if (is_vol) {
>>>>>>>>>>>>>>>                 // See comment in do_get_xxx().
>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>                 insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>                 if (is_field) {
>>>>>>>>>>>>>>>                   // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>                   set_wrote_volatile(true);
>>>>>>>>>>>>>>>                 }
>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>               }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>              __________    __________    __________    __________
>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>               write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>>                             read(y)                     read(x)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>>

From goetz.lindenmaier at sap.com  Wed Jan 22 09:20:13 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Jan 2014 17:20:13 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52DFF98C.8010001@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
	<52DE5FB0.5000808@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
	<52DED1D2.1070203@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>
	<52DFF98C.8010001@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap>

Hi Vladimir, 

> Yes, I will backport it.
That's good, thank you!

> I will build bundles and give them to SQE for final testing.
__final__   That's even better, that's great!!!

Best regards,
  Goetz.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Mittwoch, 22. Januar 2014 18:02
To: Lindenmaier, Goetz
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Hi Goetz

On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> Thanks for testing and pushing!
>
> Will you push this also to stage?  I assume we can handle this
> as the other three hotspot changes, without a new bug-id?

Yes, I will backport it.

What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581?
Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix 
from jdk9. Or I am mistaking?

>
> Also, when do you think we (you unfortunately) should update
> the repos again?  Stage-9 maybe after Volkers last change is submitted?

After I test and push 8031581 I will do sync with latest jdk9 sources (b01).
I will build bundles and give them to SQE for final testing.

Thanks,
Vladimir

>
> Best regards,
>    Goetz
>
>
>
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
> Sent: Dienstag, 21. Januar 2014 21:00
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Thanks. I am pushing it.
>
> Vladimir
>
> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>> Sorry, I missed that.  fixed.
>>
>> Best regards,
>>     Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 21. Januar 2014 12:53
>> To: Lindenmaier, Goetz; Vladimir Kozlov
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Thanks Goetz!
>>
>> This typo still exists:
>>
>> +   bool          _wrote_volatile;     // Did we write a final field?
>>
>> s/final/volatile/
>>
>> Otherwise no further comments from me.
>>
>> David
>>
>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I made a new webrev
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>> differing from
>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>> only in the comments.
>>>
>>> I removed
>>> // Support ordering of "Independent Reads of Independent Writes".
>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>> files.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Dienstag, 21. Januar 2014 05:55
>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Hi Goetz,
>>>
>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I tried to come up with a webrev that implements the change as proposed in
>>>> your mails:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>
>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>
>>> Given the flag name the commentary eg:
>>>
>>> +       // Support ordering of "Independent Reads of Independent Writes".
>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>
>>> seems somewhat redundant.
>>>
>>>> I left the definition and handling of _wrote_volatile in the code, without
>>>> any protection.
>>>
>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>
>>> s/final/volatile
>>>
>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>>> and put it on one line.
>>>>
>>>> I removed the comment in library_call.cpp.
>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>>> from the comments as it's PPC specific.
>>>
>>> I think the primary IRIW comment/explanation should go in
>>> globalDefinitions.hpp where
>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>
>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>>> issues in C1 if nobody did it by then.
>>>
>>> I've filed:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>
>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>>> platforms"
>>>
>>> to cover this task, as it may be needed sooner rather than later.
>>>
>>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>>
>>> Ok.
>>>
>>> Thanks,
>>> David
>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>> To: Vladimir Kozlov
>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>> parse.hpp.
>>>>>>>
>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>
>>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>>> have this as a build-time construct rather than a
>>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>>> use it.
>>>>>
>>>>> Any decent C++ compiler will optimize expressions with such constants
>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>>
>>>> If you insist then we may as well do it all the same way. Better to be
>>>> consistent.
>>>>
>>>> My apologies Goetz for wasting your time going back and forth on this.
>>>>
>>>> That aside I have a further concern with this IRIW support - it is
>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>>> this is going on then we (which probably means the Oracle 'we') need to
>>>> add the missing C1 code.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Vladimir
>>>>>
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>> #else
>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>> #endif
>>>>>>>
>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>
>>>>>>> and then:
>>>>>>>
>>>>>>>       #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>         oop p = JNIHandles::resolve(obj); \
>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>> OrderAccess::fence(); \
>>>>>>>         volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>
>>>>>>> And:
>>>>>>>
>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>> field->is_volatile()) {
>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>> +  }
>>>>>>>
>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>>
>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>
>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>> method()->is_initializer()) )) {
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> I updated the webrev:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>
>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>        reflect the new flagging.  Also I mention that we support the
>>>>>>>>>        volatile constructor issue, but that it's not standard.
>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>        I also think it's better to separate these this way.
>>>>>>>>
>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>> please.
>>>>>>>>
>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>
>>>>>>>>          if (is_volatile) {
>>>>>>>> !     if (!is_store) {
>>>>>>>>              insert_mem_bar(Op_MemBarAcquire);
>>>>>>>> !     } else {
>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>>              insert_mem_bar(Op_MemBarVolatile);
>>>>>>>> + #endif
>>>>>>>> +     }
>>>>>>>>
>>>>>>>> I don't think the comment is needed.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Thanks for your comments!
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>
>>>>>>>>> Hi Goetz,
>>>>>>>>>
>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>
>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>>> specifically it is
>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>>> Seems
>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>>
>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>> discussed
>>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>>> PPC64 porters.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>>> this version.
>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>> To: David Holmes
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>>> not
>>>>>>>>>>> required to pass.
>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>>> worked
>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>>> it by
>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>>> part is
>>>>>>>>>> not that performance relevant.
>>>>>>>>>>
>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>> think
>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz
>>>>>>>>>>
>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>>> emails.
>>>>>>>>>>
>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>>> settled.
>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>>
>>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>
>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>>> But I'm
>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>
>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>>> stores.
>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>> constructor tests.
>>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>>> after stores
>>>>>>>>>>>             to pass the volatile constructor tests.
>>>>>>>>>>
>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>> were not
>>>>>>>>>> required to pass.
>>>>>>>>>>
>>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>>> order
>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>>> The only instruction
>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>>> therefore the
>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>>> proper representation
>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>>> it's pointless
>>>>>>>>>>> anyways.
>>>>>>>>>>>
>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>          OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>
>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>> think
>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>>> Or also
>>>>>>>>>>>           OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>           VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>
>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>> constructor-barrier
>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>>> *may*
>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>>> ensure
>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>> invalid
>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>>> need it
>>>>>>>>>>> due to other factors).
>>>>>>>>>>>
>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>>> term :)
>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>
>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>> visible to
>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>> architectures
>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>
>>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>>> ARM and
>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>
>>>>>>>>>>>         > The fixes for the constructor issue are only needed because we
>>>>>>>>>>>         > remove the sync instruction from behind stores
>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>         > and place it before loads.
>>>>>>>>>>>
>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>>> after
>>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>>> same
>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>>> load -
>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>>> clearer.
>>>>>>>>>>>
>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>> implemented as
>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>>> hooks
>>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>
>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>>> this
>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>> or
>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>
>>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>
>>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>>> store
>>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> @David
>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>> continuous.
>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>>> issue.
>>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>>> you
>>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>>> solution,
>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>>> issues.
>>>>>>>>>>>>
>>>>>>>>>>>> @David
>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>>> and
>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>>> ARM and
>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>
>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>>> used 'read'
>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>>> above).
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>
>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>> processors
>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>
>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>
>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>
>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>> continuous.
>>>>>>>>>>>>
>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>> problem
>>>>>>>>>>>>> is that
>>>>>>>>>>>>>            store
>>>>>>>>>>>>>            sync
>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>> only
>>>>>>>>>>>>>            sync
>>>>>>>>>>>>>            load
>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>
>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>> term and
>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>            The JMM is fine. And
>>>>>>>>>>>>>            store
>>>>>>>>>>>>>            MemBarVolatile
>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>>> that
>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>              LongVolatileTest
>>>>>>>>>>>>>>              AtomicIntegerInitialValueTest
>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>>> that
>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>>> account
>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>             MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>>             MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>             MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>             MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>              MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>             MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>>> read
>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>>> few
>>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>>> will
>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>>> are not
>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>>> store
>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>>> of the
>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>>> software
>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>>> don't have
>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>>> I will
>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>            From what I understand what we see here is an attempt to
>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>>> under
>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>            From what I understand our ppc port is also affected.
>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>               if (is_vol) {
>>>>>>>>>>>>>>>                 // See comment in do_get_xxx().
>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>                 insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>                 if (is_field) {
>>>>>>>>>>>>>>>                   // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>                   set_wrote_volatile(true);
>>>>>>>>>>>>>>>                 }
>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>               }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>              __________    __________    __________    __________
>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>               write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>>                             read(y)                     read(x)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>>

From vladimir.x.ivanov at oracle.com  Wed Jan 22 09:29:32 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 22 Jan 2014 21:29:32 +0400
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during analysis
	leading to incorrect code generation
Message-ID: <52DFFFFC.2090503@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031695

CHA erroneously ignores default methods when looking for different 
versions of a method in a class hierarchy.

Consider the following hierarchy:
   interface I { default void m() { ... }}
   class A implements I {}

   class C extends A { }
   class D extends A { public void m() { ... } }

Call site: invokevirtual A.m()

A.m resolves to I.m. Searching from A, CHA finds only D.m and concludes 
that D.m is the only implementation of I.m, since 
Dependencies::is_concrete_method returns false for I.m.

But there is C with default implementation from I. So, if VM inlines D.m 
and then C's instance is passed as objectref, the wrong method is 
invoked (D.m instead of I.m).

The fix is to take default methods into account doing CHA analysis and 
treat the call site as non-monomorphic when a concrete method is found 
for a default method.

Conservative approach is chosen, since the fix is targeted for 8.

Testing: failing application, regression test, vm.defmeth.testlist, JDK 
regression tests (java/util/, java/lang)

Thanks!

Best regards,
Vladimir Ivanov

From volker.simonis at gmail.com  Wed Jan 22 09:42:18 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 22 Jan 2014 18:42:18 +0100
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52DFF98C.8010001@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<52968167.4050906@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap>
	<52B3CE56.9030205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
	<52DE5FB0.5000808@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
	<52DED1D2.1070203@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>
	<52DFF98C.8010001@oracle.com>
Message-ID: <CA+3eh11GhX7_TFAo=WUC8ngFVuhmn95vdSmT=S6EnCANieFEbQ@mail.gmail.com>

On Wed, Jan 22, 2014 at 6:02 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Hi Goetz
>
>
> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
>>
>> Hi Vladimir,
>>
>> Thanks for testing and pushing!
>>
>> Will you push this also to stage?  I assume we can handle this
>> as the other three hotspot changes, without a new bug-id?
>
>
> Yes, I will backport it.
>
> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one
> from today 8031581?
> Should I backport all of them into 8u stage? From conversion between Volker
> and Alan some of them need backport a fix from jdk9. Or I am mistaking?
>

It would be great if you could push 8028537, 8031134, 8031997 and
8031581 into 8u stage.

There is no real source-code level dependency between these changes
and the change "7133499: (fc) FileChannel.read not preempted by
asynchronous close on OS X)" which is still to be pushed by Alan to
jdk9. However the AIX-port will automatically benefit from 7133499
once it will be pushed.

>
>>
>> Also, when do you think we (you unfortunately) should update
>> the repos again?  Stage-9 maybe after Volkers last change is submitted?
>
>
> After I test and push 8031581 I will do sync with latest jdk9 sources (b01).

It would be great if you could push the change from:

http://cr.openjdk.java.net/~simonis/webrevs/8031581_3

It is exactly the same like the one from
http://cr.openjdk.java.net/~simonis/webrevs/8031581_2 with only one
comment line changed to fix the typo "legel"->"legal" in
src/share/native/java/util/zip/zip_util.c .

Thanks a lot,
Volker

> I will build bundles and give them to SQE for final testing.
>
> Thanks,
> Vladimir
>
>
>>
>> Best regards,
>>    Goetz
>>
>>
>>
>> -----Original Message-----
>> From: hotspot-dev-bounces at openjdk.java.net
>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
>> Sent: Dienstag, 21. Januar 2014 21:00
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
>> Reads of Independent Writes
>>
>> Thanks. I am pushing it.
>>
>> Vladimir
>>
>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>>>
>>> Sorry, I missed that.  fixed.
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Dienstag, 21. Januar 2014 12:53
>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
>>> Reads of Independent Writes
>>>
>>> Thanks Goetz!
>>>
>>> This typo still exists:
>>>
>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>
>>> s/final/volatile/
>>>
>>> Otherwise no further comments from me.
>>>
>>> David
>>>
>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>>>
>>>> Hi,
>>>>
>>>> I made a new webrev
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>>> differing from
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>> only in the comments.
>>>>
>>>> I removed
>>>> // Support ordering of "Independent Reads of Independent Writes".
>>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>>> files.
>>>>
>>>> Best regards,
>>>>      Goetz.
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Dienstag, 21. Januar 2014 05:55
>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
>>>> Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I tried to come up with a webrev that implements the change as proposed
>>>>> in
>>>>> your mails:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>>
>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>>
>>>>
>>>> Given the flag name the commentary eg:
>>>>
>>>> +       // Support ordering of "Independent Reads of Independent
>>>> Writes".
>>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>>
>>>> seems somewhat redundant.
>>>>
>>>>> I left the definition and handling of _wrote_volatile in the code,
>>>>> without
>>>>> any protection.
>>>>
>>>>
>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>
>>>> s/final/volatile
>>>>
>>>>> I protected issuing the barrier for volatile in constructors with
>>>>> PPC64_ONLY() ,
>>>>> and put it on one line.
>>>>>
>>>>> I removed the comment in library_call.cpp.
>>>>> I also removed the sentence " Solution: implement volatile read as
>>>>> sync-load-acquire."
>>>>> from the comments as it's PPC specific.
>>>>
>>>>
>>>> I think the primary IRIW comment/explanation should go in
>>>> globalDefinitions.hpp where
>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>>
>>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we
>>>>> will fix these
>>>>> issues in C1 if nobody did it by then.
>>>>
>>>>
>>>> I've filed:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>>
>>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>>>> platforms"
>>>>
>>>> to cover this task, as it may be needed sooner rather than later.
>>>>
>>>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If
>>>>> any
>>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent
>>>>> this.
>>>>
>>>>
>>>> Ok.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Best regards,
>>>>>       Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>>> To: Vladimir Kozlov
>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net';
>>>>> 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
>>>>> Reads of Independent Writes
>>>>>
>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>>>
>>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>>>
>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>>>
>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>>>> want to keep it this way, it could be useful to have such info on
>>>>>>>> other
>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>>> parse.hpp.
>>>>>>>>
>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a
>>>>>>>> value
>>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>>
>>>>>>>
>>>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>>>> have this as a build-time construct rather than a
>>>>>>> runtime one. I don't want to have to pay anything for this if we
>>>>>>> don't
>>>>>>> use it.
>>>>>>
>>>>>>
>>>>>> Any decent C++ compiler will optimize expressions with such constants
>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I
>>>>>> really
>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>>>
>>>>>
>>>>> If you insist then we may as well do it all the same way. Better to be
>>>>> consistent.
>>>>>
>>>>> My apologies Goetz for wasting your time going back and forth on this.
>>>>>
>>>>> That aside I have a further concern with this IRIW support - it is
>>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>>>> this is going on then we (which probably means the Oracle 'we') need to
>>>>> add the missing C1 code.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>>> #else
>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>>
>>>>>>>> and then:
>>>>>>>>
>>>>>>>>       #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>>         oop p = JNIHandles::resolve(obj); \
>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>>> OrderAccess::fence(); \
>>>>>>>>         volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>>
>>>>>>>> And:
>>>>>>>>
>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>>> field->is_volatile()) {
>>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>>> +  }
>>>>>>>>
>>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>>>
>>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>>
>>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>>> method()->is_initializer()) )) {
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>>>
>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> I updated the webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>
>>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>>        reflect the new flagging.  Also I mention that we support
>>>>>>>>>> the
>>>>>>>>>>        volatile constructor issue, but that it's not standard.
>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>>        I also think it's better to separate these this way.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>>> please.
>>>>>>>>>
>>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>>
>>>>>>>>>          if (is_volatile) {
>>>>>>>>> !     if (!is_store) {
>>>>>>>>>              insert_mem_bar(Op_MemBarAcquire);
>>>>>>>>> !     } else {
>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store,
>>>>>>>>> sync-load-acquire.
>>>>>>>>>              insert_mem_bar(Op_MemBarVolatile);
>>>>>>>>> + #endif
>>>>>>>>> +     }
>>>>>>>>>
>>>>>>>>> I don't think the comment is needed.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Thanks for your comments!
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>        Goetz.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>>
>>>>>>>>>> The general changes to the volatile barriers to support IRIW are
>>>>>>>>>> okay.
>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though
>>>>>>>>>> more
>>>>>>>>>> specifically it is
>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much
>>>>>>>>>> of
>>>>>>>>>> the commentary excessive, particularly for shared code. In
>>>>>>>>>> particular
>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give
>>>>>>>>>> the
>>>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>>>> Seems
>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite
>>>>>>>>>> adequate.
>>>>>>>>>>
>>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>>> discussed
>>>>>>>>>> are not required by the Java Memory Model. If you want to keep
>>>>>>>>>> these
>>>>>>>>>> then I think they should all be guarded with PPC64 because it is
>>>>>>>>>> not
>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by
>>>>>>>>>> the
>>>>>>>>>> PPC64 porters.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when
>>>>>>>>>>> editing
>>>>>>>>>>> this version.
>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>         Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>>> To: David Holmes
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>>>> were
>>>>>>>>>>>> not
>>>>>>>>>>>> required to pass.
>>>>>>>>>>>
>>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that
>>>>>>>>>>> it's
>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>>>> worked
>>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would
>>>>>>>>>>> guard
>>>>>>>>>>> it by
>>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also,
>>>>>>>>>>> this
>>>>>>>>>>> part is
>>>>>>>>>>> not that performance relevant.
>>>>>>>>>>>
>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one
>>>>>>>>>>>> I
>>>>>>>>>>>> think
>>>>>>>>>>>
>>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>         Goetz
>>>>>>>>>>>
>>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to
>>>>>>>>>>> check
>>>>>>>>>>> emails.
>>>>>>>>>>>
>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>>>> settled.
>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the
>>>>>>>>>>>> proof!
>>>>>>>>>>>>
>>>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>>>> But I'm
>>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>>
>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>>>> stores.
>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>>> constructor tests.
>>>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>>>> after stores
>>>>>>>>>>>>             to pass the volatile constructor tests.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>>> were not
>>>>>>>>>>> required to pass.
>>>>>>>>>>>
>>>>>>>>>>>> We originally passed the constructor tests because the ppc
>>>>>>>>>>>> memory
>>>>>>>>>>>> order
>>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>>>> The only instruction
>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does
>>>>>>>>>>>> StoreStore,
>>>>>>>>>>>> therefore the
>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>>>> proper representation
>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But
>>>>>>>>>>>> now
>>>>>>>>>>>> it's pointless
>>>>>>>>>>>> anyways.
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>>          OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>> think
>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something
>>>>>>>>>>> semantic
>>>>>>>>>>> based not architecture based) as that will allows for turning
>>>>>>>>>>> this
>>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> or the like to guard the customization.  I'd like that much
>>>>>>>>>>>> better.
>>>>>>>>>>>> Or also
>>>>>>>>>>>>           OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>           VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>>
>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>>> constructor-barrier
>>>>>>>>>>>> for volatiles is not required as part of the JMM specification.
>>>>>>>>>>>> It
>>>>>>>>>>>> *may*
>>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>>>> ensure
>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>>> invalid
>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>>>> need it
>>>>>>>>>>>> due to other factors).
>>>>>>>>>>>>
>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>>>> term :)
>>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>>
>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and
>>>>>>>>>>>> a
>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>>> visible to
>>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>>> architectures
>>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>>
>>>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>>>> ARM and
>>>>>>>>>>>> PPC. But of course it is normally handled by using suitable
>>>>>>>>>>>> barriers
>>>>>>>>>>>> after the stores that need to be visible. I think the crux of
>>>>>>>>>>>> the
>>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>>
>>>>>>>>>>>>         > The fixes for the constructor issue are only needed
>>>>>>>>>>>> because we
>>>>>>>>>>>>         > remove the sync instruction from behind stores
>>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>>         > and place it before loads.
>>>>>>>>>>>>
>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>>>> after
>>>>>>>>>>>> the store then you have to do something around the loads to get
>>>>>>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>> results! I still don't know what lead you to the conclusion that
>>>>>>>>>>>> the
>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>>>> load -
>>>>>>>>>>>> maybe when I get the chance to read that paper in full it will
>>>>>>>>>>>> be
>>>>>>>>>>>> clearer.
>>>>>>>>>>>>
>>>>>>>>>>>> So ... the basic problem is that the current structure in the VM
>>>>>>>>>>>> has
>>>>>>>>>>>> hard-wired one choice of how to get the right semantics for
>>>>>>>>>>>> volatile
>>>>>>>>>>>> variables. You now want to customize that but not all the
>>>>>>>>>>>> requisite
>>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>>> implemented as
>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and
>>>>>>>>>>>> post-
>>>>>>>>>>>> hooks
>>>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I
>>>>>>>>>>>> think
>>>>>>>>>>>> this
>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The
>>>>>>>>>>>> barrier
>>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>> or
>>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the
>>>>>>>>>>>>> JMM
>>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we
>>>>>>>>>>>>> think
>>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad
>>>>>>>>>>>>> if
>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>>>> and place it before loads.  Then there is no sync between
>>>>>>>>>>>>> volatile
>>>>>>>>>>>>> store
>>>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on
>>>>>>>>>>>>> this
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>> And we came up with a solution we consider the best possible.
>>>>>>>>>>>>> If
>>>>>>>>>>>>> you
>>>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>>>> solution,
>>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>>>> term
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity,
>>>>>>>>>>>>> I
>>>>>>>>>>>>> used 'read'
>>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method
>>>>>>>>>>>>> name
>>>>>>>>>>>>> above).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>>> processors
>>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>> taskqueue
>>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.
>>>>>>>>>>>>>> Therefore
>>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>            store
>>>>>>>>>>>>>>            sync
>>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>            sync
>>>>>>>>>>>>>>            load
>>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>>> term and
>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>            The JMM is fine. And
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>            store
>>>>>>>>>>>>>>            MemBarVolatile
>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler
>>>>>>>>>>>>>> instructions
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by
>>>>>>>>>>>>>>>> JMM
>>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>>              LongVolatileTest
>>>>>>>>>>>>>>>              AtomicIntegerInitialValueTest
>>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the
>>>>>>>>>>>>>> JMM
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due
>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.
>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>>>> account
>>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>>             MemBarRelease    // means LoadStore, StoreStore
>>>>>>>>>>>>>>> barrier
>>>>>>>>>>>>>>>             MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>             MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>>             MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>>              MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>>             MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC
>>>>>>>>>>>>>>> operations
>>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> read
>>>>>>>>>>>>>>> is inefficient on platforms that have
>>>>>>>>>>>>>>> multiple-read-atomicity.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail
>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>> few
>>>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>>> volatile accesses is if there are global visibility issues
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>>>> store
>>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds
>>>>>>>>>>>>>> me
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>>>> software
>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>>>> don't have
>>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of
>>>>>>>>>>>>>> days
>>>>>>>>>>>>>> I will
>>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant,
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you
>>>>>>>>>>>>>>> wish, I
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a
>>>>>>>>>>>>>>> reasonable
>>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>            From what I understand what we see here is an
>>>>>>>>>>>>>>> attempt to
>>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I
>>>>>>>>>>>>>>> said
>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not
>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not
>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change
>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits()
>>>>>>>>>>>>>>>> now).
>>>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the
>>>>>>>>>>>>>>> JMM
>>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>            From what I understand our ppc port is also
>>>>>>>>>>>>>>>> affected.
>>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>               if (is_vol) {
>>>>>>>>>>>>>>>>                 // See comment in do_get_xxx().
>>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>>                 insert_mem_bar(Op_MemBarVolatile); // Use
>>>>>>>>>>>>>>>> fat membar
>>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>>                 if (is_field) {
>>>>>>>>>>>>>>>>                   // Add MemBarRelease for constructors
>>>>>>>>>>>>>>>> which write
>>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>>                   set_wrote_volatile(true);
>>>>>>>>>>>>>>>>                 }
>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>               }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>>              __________    __________    __________
>>>>>>>>>>>>>>>>> __________
>>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>               write(x=1)    read(x)       write(y=1)
>>>>>>>>>>>>>>>>> read(y)
>>>>>>>>>>>>>>>>>                             read(y)
>>>>>>>>>>>>>>>>> read(x)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity.
>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that
>>>>>>>>>>>>>>>>> volatile
>>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>>> written in constructors are visible before the reference
>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>>>
>

From john.r.rose at oracle.com  Wed Jan 22 10:09:29 2014
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 22 Jan 2014 10:09:29 -0800
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during
	analysis leading to incorrect code generation
In-Reply-To: <52DFFFFC.2090503@oracle.com>
References: <52DFFFFC.2090503@oracle.com>
Message-ID: <FD9564FB-FBB0-4D0A-BD8E-BF440CF3350C@oracle.com>

Good fix; reviewed.  ? John

On Jan 22, 2014, at 9:29 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8031695
> 
> CHA erroneously ignores default methods when looking for different versions of a method in a class hierarchy.
> 
> Consider the following hierarchy:
>  interface I { default void m() { ... }}
>  class A implements I {}
> 
>  class C extends A { }
>  class D extends A { public void m() { ... } }
> 
> Call site: invokevirtual A.m()
> 
> A.m resolves to I.m. Searching from A, CHA finds only D.m and concludes that D.m is the only implementation of I.m, since Dependencies::is_concrete_method returns false for I.m.
> 
> But there is C with default implementation from I. So, if VM inlines D.m and then C's instance is passed as objectref, the wrong method is invoked (D.m instead of I.m).
> 
> The fix is to take default methods into account doing CHA analysis and treat the call site as non-monomorphic when a concrete method is found for a default method.
> 
> Conservative approach is chosen, since the fix is targeted for 8.
> 
> Testing: failing application, regression test, vm.defmeth.testlist, JDK regression tests (java/util/, java/lang)
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov


From karen.kinnear at oracle.com  Wed Jan 22 11:16:59 2014
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 22 Jan 2014 14:16:59 -0500
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during
	analysis leading to incorrect code generation
In-Reply-To: <52DFFFFC.2090503@oracle.com>
References: <52DFFFFC.2090503@oracle.com>
Message-ID: <968D31A3-8211-4D3E-A346-62BA4A0BD7F4@oracle.com>

Looks good.

many thanks,
Karen

On Jan 22, 2014, at 12:29 PM, Vladimir Ivanov wrote:

> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8031695
> 
> CHA erroneously ignores default methods when looking for different versions of a method in a class hierarchy.
> 
> Consider the following hierarchy:
>  interface I { default void m() { ... }}
>  class A implements I {}
> 
>  class C extends A { }
>  class D extends A { public void m() { ... } }
> 
> Call site: invokevirtual A.m()
> 
> A.m resolves to I.m. Searching from A, CHA finds only D.m and concludes that D.m is the only implementation of I.m, since Dependencies::is_concrete_method returns false for I.m.
> 
> But there is C with default implementation from I. So, if VM inlines D.m and then C's instance is passed as objectref, the wrong method is invoked (D.m instead of I.m).
> 
> The fix is to take default methods into account doing CHA analysis and treat the call site as non-monomorphic when a concrete method is found for a default method.
> 
> Conservative approach is chosen, since the fix is targeted for 8.
> 
> Testing: failing application, regression test, vm.defmeth.testlist, JDK regression tests (java/util/, java/lang)
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov


From harold.seigel at oracle.com  Wed Jan 22 11:40:46 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 22 Jan 2014 14:40:46 -0500
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during analysis
	leading to incorrect code generation
In-Reply-To: <52DFFFFC.2090503@oracle.com>
References: <52DFFFFC.2090503@oracle.com>
Message-ID: <52E01EBE.8010200@oracle.com>

Hi Vladimir.

Does this second version of is_concrete_method() also need a "&& 
!m->is_overpass()"?

1191 bool Dependencies::is_concrete_method(ciMethod* m) {
1192   // Statics are irrelevant to virtual call sites.
1193   if (m->is_static())  return false;
1194
1195   // We could also return false if m does not yet appear to be
1196   // executed, if the VM version supports this distinction also.
1197   return !m->is_abstract();
1198 }

Thanks, Harold


On 1/22/2014 12:29 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8031695
>
> CHA erroneously ignores default methods when looking for different 
> versions of a method in a class hierarchy.
>
> Consider the following hierarchy:
>   interface I { default void m() { ... }}
>   class A implements I {}
>
>   class C extends A { }
>   class D extends A { public void m() { ... } }
>
> Call site: invokevirtual A.m()
>
> A.m resolves to I.m. Searching from A, CHA finds only D.m and 
> concludes that D.m is the only implementation of I.m, since 
> Dependencies::is_concrete_method returns false for I.m.
>
> But there is C with default implementation from I. So, if VM inlines 
> D.m and then C's instance is passed as objectref, the wrong method is 
> invoked (D.m instead of I.m).
>
> The fix is to take default methods into account doing CHA analysis and 
> treat the call site as non-monomorphic when a concrete method is found 
> for a default method.
>
> Conservative approach is chosen, since the fix is targeted for 8.
>
> Testing: failing application, regression test, vm.defmeth.testlist, 
> JDK regression tests (java/util/, java/lang)
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Wed Jan 22 12:27:05 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 23 Jan 2014 00:27:05 +0400
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during analysis
	leading to incorrect code generation
In-Reply-To: <52E01EBE.8010200@oracle.com>
References: <52DFFFFC.2090503@oracle.com> <52E01EBE.8010200@oracle.com>
Message-ID: <52E02999.9060403@oracle.com>

Harold,

I'm reluctant to change it with this fix.

Dependencies::is_concrete_method(ciMethod* m) isn't called from anywhere 
and it already diverged a bit from Method* version. Also, method type 
(normal or overpass) isn't cached in ciMethod, so is_overpass() isn't 
available unless corresponding Method is queries instead.

At least, it needs additional investigation. Probably, this function 
should go away or delegate to Method* version.

Thanks for looking into the fix!

Best regards,
Vladimir Ivanov

On 1/22/14 11:40 PM, harold seigel wrote:
> Hi Vladimir.
>
> Does this second version of is_concrete_method() also need a "&&
> !m->is_overpass()"?
>
> 1191 bool Dependencies::is_concrete_method(ciMethod* m) {
> 1192   // Statics are irrelevant to virtual call sites.
> 1193   if (m->is_static())  return false;
> 1194
> 1195   // We could also return false if m does not yet appear to be
> 1196   // executed, if the VM version supports this distinction also.
> 1197   return !m->is_abstract();
> 1198 }
>
> Thanks, Harold
>
>
> On 1/22/2014 12:29 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8031695
>>
>> CHA erroneously ignores default methods when looking for different
>> versions of a method in a class hierarchy.
>>
>> Consider the following hierarchy:
>>   interface I { default void m() { ... }}
>>   class A implements I {}
>>
>>   class C extends A { }
>>   class D extends A { public void m() { ... } }
>>
>> Call site: invokevirtual A.m()
>>
>> A.m resolves to I.m. Searching from A, CHA finds only D.m and
>> concludes that D.m is the only implementation of I.m, since
>> Dependencies::is_concrete_method returns false for I.m.
>>
>> But there is C with default implementation from I. So, if VM inlines
>> D.m and then C's instance is passed as objectref, the wrong method is
>> invoked (D.m instead of I.m).
>>
>> The fix is to take default methods into account doing CHA analysis and
>> treat the call site as non-monomorphic when a concrete method is found
>> for a default method.
>>
>> Conservative approach is chosen, since the fix is targeted for 8.
>>
>> Testing: failing application, regression test, vm.defmeth.testlist,
>> JDK regression tests (java/util/, java/lang)
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>

From vladimir.x.ivanov at oracle.com  Wed Jan 22 12:34:41 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 23 Jan 2014 00:34:41 +0400
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during analysis
	leading to incorrect code generation
In-Reply-To: <968D31A3-8211-4D3E-A346-62BA4A0BD7F4@oracle.com>
References: <52DFFFFC.2090503@oracle.com>
	<968D31A3-8211-4D3E-A346-62BA4A0BD7F4@oracle.com>
Message-ID: <52E02B61.102@oracle.com>

John, Karen, thanks for review!

Special thanks goes to Lois for initial analysis and instructions how to 
reproduce the issue. It saved me lots of time.

Best regards,
Vladimir Ivanov

On 1/22/14 11:16 PM, Karen Kinnear wrote:
> Looks good.
>
> many thanks,
> Karen
>
> On Jan 22, 2014, at 12:29 PM, Vladimir Ivanov wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8031695
>>
>> CHA erroneously ignores default methods when looking for different versions of a method in a class hierarchy.
>>
>> Consider the following hierarchy:
>>   interface I { default void m() { ... }}
>>   class A implements I {}
>>
>>   class C extends A { }
>>   class D extends A { public void m() { ... } }
>>
>> Call site: invokevirtual A.m()
>>
>> A.m resolves to I.m. Searching from A, CHA finds only D.m and concludes that D.m is the only implementation of I.m, since Dependencies::is_concrete_method returns false for I.m.
>>
>> But there is C with default implementation from I. So, if VM inlines D.m and then C's instance is passed as objectref, the wrong method is invoked (D.m instead of I.m).
>>
>> The fix is to take default methods into account doing CHA analysis and treat the call site as non-monomorphic when a concrete method is found for a default method.
>>
>> Conservative approach is chosen, since the fix is targeted for 8.
>>
>> Testing: failing application, regression test, vm.defmeth.testlist, JDK regression tests (java/util/, java/lang)
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>

From harold.seigel at oracle.com  Wed Jan 22 12:40:42 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 22 Jan 2014 15:40:42 -0500
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during analysis
	leading to incorrect code generation
In-Reply-To: <52E02999.9060403@oracle.com>
References: <52DFFFFC.2090503@oracle.com> <52E01EBE.8010200@oracle.com>
	<52E02999.9060403@oracle.com>
Message-ID: <52E02CCA.6070401@oracle.com>

Hi Vladimir,

Thanks for the explanation.

Harold

On 1/22/2014 3:27 PM, Vladimir Ivanov wrote:
> Harold,
>
> I'm reluctant to change it with this fix.
>
> Dependencies::is_concrete_method(ciMethod* m) isn't called from 
> anywhere and it already diverged a bit from Method* version. Also, 
> method type (normal or overpass) isn't cached in ciMethod, so 
> is_overpass() isn't available unless corresponding Method is queries 
> instead.
>
> At least, it needs additional investigation. Probably, this function 
> should go away or delegate to Method* version.
>
> Thanks for looking into the fix!
>
> Best regards,
> Vladimir Ivanov
>
> On 1/22/14 11:40 PM, harold seigel wrote:
>> Hi Vladimir.
>>
>> Does this second version of is_concrete_method() also need a "&&
>> !m->is_overpass()"?
>>
>> 1191 bool Dependencies::is_concrete_method(ciMethod* m) {
>> 1192   // Statics are irrelevant to virtual call sites.
>> 1193   if (m->is_static())  return false;
>> 1194
>> 1195   // We could also return false if m does not yet appear to be
>> 1196   // executed, if the VM version supports this distinction also.
>> 1197   return !m->is_abstract();
>> 1198 }
>>
>> Thanks, Harold
>>
>>
>> On 1/22/2014 12:29 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8031695
>>>
>>> CHA erroneously ignores default methods when looking for different
>>> versions of a method in a class hierarchy.
>>>
>>> Consider the following hierarchy:
>>>   interface I { default void m() { ... }}
>>>   class A implements I {}
>>>
>>>   class C extends A { }
>>>   class D extends A { public void m() { ... } }
>>>
>>> Call site: invokevirtual A.m()
>>>
>>> A.m resolves to I.m. Searching from A, CHA finds only D.m and
>>> concludes that D.m is the only implementation of I.m, since
>>> Dependencies::is_concrete_method returns false for I.m.
>>>
>>> But there is C with default implementation from I. So, if VM inlines
>>> D.m and then C's instance is passed as objectref, the wrong method is
>>> invoked (D.m instead of I.m).
>>>
>>> The fix is to take default methods into account doing CHA analysis and
>>> treat the call site as non-monomorphic when a concrete method is found
>>> for a default method.
>>>
>>> Conservative approach is chosen, since the fix is targeted for 8.
>>>
>>> Testing: failing application, regression test, vm.defmeth.testlist,
>>> JDK regression tests (java/util/, java/lang)
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>


From lois.foltan at oracle.com  Wed Jan 22 12:48:32 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 22 Jan 2014 15:48:32 -0500
Subject: [8] RFR (XS): 8031695: CHA ignores default methods during analysis
	leading to incorrect code generation
In-Reply-To: <52E02B61.102@oracle.com>
References: <52DFFFFC.2090503@oracle.com>
	<968D31A3-8211-4D3E-A346-62BA4A0BD7F4@oracle.com>
	<52E02B61.102@oracle.com>
Message-ID: <52E02EA0.3090300@oracle.com>


On 1/22/2014 3:34 PM, Vladimir Ivanov wrote:
> John, Karen, thanks for review!
>
> Special thanks goes to Lois for initial analysis and instructions how 
> to reproduce the issue. It saved me lots of time.

Hi Vladimir,
Thanks, your change looks good and as I mentioned earlier I tried it 
with the test case and all is fine.  I would also be remiss not to point 
out that Christian Tornqvist also was very helpful in diagnosing key 
aspects about this problem.  Thanks Christian!
Lois

>
> Best regards,
> Vladimir Ivanov
>
> On 1/22/14 11:16 PM, Karen Kinnear wrote:
>> Looks good.
>>
>> many thanks,
>> Karen
>>
>> On Jan 22, 2014, at 12:29 PM, Vladimir Ivanov wrote:
>>
>>> http://cr.openjdk.java.net/~vlivanov/8031695/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8031695
>>>
>>> CHA erroneously ignores default methods when looking for different 
>>> versions of a method in a class hierarchy.
>>>
>>> Consider the following hierarchy:
>>>   interface I { default void m() { ... }}
>>>   class A implements I {}
>>>
>>>   class C extends A { }
>>>   class D extends A { public void m() { ... } }
>>>
>>> Call site: invokevirtual A.m()
>>>
>>> A.m resolves to I.m. Searching from A, CHA finds only D.m and 
>>> concludes that D.m is the only implementation of I.m, since 
>>> Dependencies::is_concrete_method returns false for I.m.
>>>
>>> But there is C with default implementation from I. So, if VM inlines 
>>> D.m and then C's instance is passed as objectref, the wrong method 
>>> is invoked (D.m instead of I.m).
>>>
>>> The fix is to take default methods into account doing CHA analysis 
>>> and treat the call site as non-monomorphic when a concrete method is 
>>> found for a default method.
>>>
>>> Conservative approach is chosen, since the fix is targeted for 8.
>>>
>>> Testing: failing application, regression test, vm.defmeth.testlist, 
>>> JDK regression tests (java/util/, java/lang)
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>


From david.holmes at oracle.com  Wed Jan 22 14:56:48 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2014 08:56:48 +1000
Subject: RFR: JDK9: 8028407: adjust-mflags.sh failed build with GNU Make
	4.0 with -I<path contains j>
In-Reply-To: <52DFF1C9.10107@oracle.com>
References: <52D98C9E.8070906@oracle.com>	<52DD1C8A.4020502@oracle.com>	<52DEBA66.3030709@oracle.com>	<52DF1222.8000602@oracle.com>	<52DF4D56.6070107@oracle.com>
	<52DF6B6F.7000708@oracle.com> <52DF6E1B.1060903@oracle.com>
	<52DFF1C9.10107@oracle.com>
Message-ID: <52E04CB0.6010807@oracle.com>

Added back build-dev as this email thread split into two :(

On 23/01/2014 2:28 AM, Henry Jen wrote:
> I need to know better for hotspot process, which is why I was looking
> for a sponsor. Hopefully to adress the concerns,
>
> - I had done jprt before the push

To be clear hotspot changes must be pushed via JPRT, it isn't a two step 
process whereby you run JPRT then do a push. For this you simply create 
the changeset and then do

jprt submit -forest -c "NNNNN: synopsis"

> - This patch had been looked at in the past, hopefully I can count David
> as another reviewer as he understood this issue from last discussion.

Yes I would have been a reviewer.

David
-----

> Cheers,
> Henry
>
> On 01/21/2014 11:07 PM, David Holmes wrote:
>> Henry,
>>
>> hotspot changes also traditionally require two reviewers, unlike
>> core-libs. Though given the rules are now set by the jdk9 project it
>> isn't clear how that can be enforced :(
>>
>> David
>>
>> On 22/01/2014 4:55 PM, Alejandro E Murillo wrote:
>>>
>>> On 1/21/2014 9:47 PM, Henry Jen wrote:
>>>> On 01/21/2014 04:34 PM, Alejandro E Murillo wrote:
>>>>>
>>>>> On 1/21/2014 11:20 AM, Henry Jen wrote:
>>>>>>
>>>>>> On 01/20/2014 04:54 AM, Erik Joelsson wrote:
>>>>>>> I suggested the change back then and even though I had to think
>>>>>>> for a
>>>>>>> while to figure out what it did, it still looks correct.
>>>>>>>
>>>>>>> As for pushing, as a jdk9 committer, it is my understanding that
>>>>>>> you are
>>>>>>> allowed to push it yourself to Hotspot, as long as you use Jprt and
>>>>>>> push
>>>>>>> to the correct group repo.
>>>>>>>
>>>>>>
>>>>>> Cool, I will do that and push to jdk9/dev/hotspot.
>>>>> you should push this to a hotspot group repo.
>>>>> I suggest you push it to: jdk9/hs-rt/hotspot
>>>>>
>>>>
>>>> Sorry I had pushed this before read this email, I assume the
>>>> propagation will happen eventually.
>>>>
>>>> Also I think it won't hurt if anyone in hotspot group would like to
>>>> cherry-pick that particular changeset.
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8d4d0db1f06
>>>>
>>>> Apologize if this cause any inconvinience.
>>>>
>>>> Cheers,
>>>> Henry
>>> Erik's email, that you replied, indicated that this should have
>>> been pushed to the right repo and using JPRT.
>>> doesn't look like you used JPRT to push this change either,
>>> Hotspot changes must be pushed using JPRT.
>>>
>>> the propagation will happen, but the problem is that
>>> it won't get proper nightly or PIT testing on that repo before
>>> going to master.
>>>
>>> If you didn't push using JPRT, then please run a non pushing hotspot
>>> job to verify all the bundles, including embedded ones, are building
>>> without problem.
>>>
>>> Thanks
>>>

From vladimir.x.ivanov at oracle.com  Wed Jan 22 16:01:59 2014
From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com)
Date: Thu, 23 Jan 2014 00:01:59 +0000
Subject: hg: hsx/hotspot-main/hotspot: 8031695: CHA ignores default methods
	during analysis leading to incorrect code generation
Message-ID: <20140123000201.61F116269A@hg.openjdk.java.net>

Changeset: 709018897c81
Author:    vlivanov
Date:      2014-01-23 01:23 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/709018897c81

8031695: CHA ignores default methods during analysis leading to incorrect code generation
Reviewed-by: jrose, acorn, hseigel, lfoltan

! src/share/vm/code/dependencies.cpp
+ test/compiler/inlining/DefaultAndConcreteMethodsCHA.java


From mike.duigou at oracle.com  Wed Jan 22 17:05:40 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 22 Jan 2014 17:05:40 -0800
Subject: RFR: 8030350: Enable additional compiler warnings for GCC
In-Reply-To: <86B8D7B3-7968-4101-8A15-E0A62646A975@oracle.com>
References: <86B8D7B3-7968-4101-8A15-E0A62646A975@oracle.com>
Message-ID: <61DD4453-9A68-42A4-96EC-4918332AB770@oracle.com>

Ping! 

Still seeking reviewer and hotspot sponsor.

Mike

On Jan 16 2014, at 18:18 , Mike Duigou <mike.duigou at oracle.com> wrote:

> Hello all;
> 
> I've done some additional testing of my previous patch enabling additional GCC warnings for native code.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8030350/4/webrev/
> 
> With the switch to -Wformat=2 I found it necessary to add -Wno-error=format-nonliteral for hotspot as there are legitimate calls to sscanf that use a passed parameter.
> 
> In addition to review I still need a sponsor to push this to hotspot for me.
> 
> Thanks,
> 
> Mike
> 


From david.holmes at oracle.com  Wed Jan 22 21:53:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2014 15:53:06 +1000
Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory
	ordering for object initialization
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F125@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap>	<52B3A3AF.9050609@oracle.com>
	<52D76E6F.8070504@oracle.com>	<52D821CB.6020207@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap>	<52DC8DA9.2010106@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap>	<52DDE01D.1060605@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8F125@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E0AE42.7050306@oracle.com>

On 23/01/2014 12:01 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> thanks for the hint to this paper, David!
> We modified the known read-after-write test to use the serialization page
> mechanism, and reading that paper we were able to understand it is correct
> on X86 / TSO.  Thanks to Andreas Schoesser for this.
> http://cr.openjdk.java.net/~goetz/raw_serialization_page/raw_s11n_page.cpp
>
> We ran the test on linux ppc and aix over the weekend, without failure.
> This indicates the mechanism works there, too.

Well, as you know, testing can only prove the presence of bugs ...

The conditions under which this might fail are subtle and might never 
arise in a direct test.

> The test fails immediately if the "write" in the fast thread is omitted.
> We also checked that both threads make considerable progress, and the
> fast thread does not always trap.
>
> Also, we looked at documentation about how mprotect etc should
> be implemented on ppc.
> A mprotect should do a tlbie, invidating the TLBs of all processors.
> It also should do an eieio and a tlbsync
> This assures the TLB of the "fast" process doing only the write is
> invalidated before mprotect returns.  So the fast thread will
> experience a TLB-miss on the write.  We assume on the TLB-miss
> some synchronization instruction is used, probably the ptesync.
> This should assure the fast thread gets the new value even if the
> page is already writable again.
> Unfortunately this is implemented in supervisor code, which is not
> available to us.
>
> I'll add a patch that enables UseMembar in our VM to test the performance
> impacts of that variant.
> As I don't see a good reason this flag is product, I'll change it to
> debug for the test.

There are very good reasons for it being a product flag as it has proven 
invaluable over the years in identifying memory-ordering race conditions 
ie missing barriers.

   As you described, the flag should be set depending on
> whether the serialization page works.  So nowadays it serves as a platform
> configuration so I think debug is the better choice.
> (Btw, you could move UsePPCLWSYNC into your globals_ppc.hpp with the new
> platform-dependent flags.)

I never realized it was there else I would have moved it long ago.

Thanks,
David

>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 21. Januar 2014 03:49
> To: Lindenmaier, Goetz; Vladimir Kozlov
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>
> On 20/01/2014 11:41 PM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> I understand your arguments and basically agree with them.
>> If the serialization page does not work on PPC, your solution
>> 1) is best.
>>
>> But I'm not sure why there should be a link between TSO and whether
>> the serialization page trick works.  Second depends, as you say,
>> on the OS implementation.
>
> My limited understanding is that on RMO-based systems the requirements for:
>
> "Synchronization based on page-protections - mprotect()"
>
> as described in:
>
> http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt
>
> may not always hold. Dave Dice would need to provide more details if needed.
>
> Cheers,
> David
>
>> I would assume that the write to the serialization page causes
>> the OS to generate a new TLB entry or the like, involving the
>> use of a ptwsync instruction which would be fine.  But we are
>> investigating this.
>>
>> We are also experimenting with a small regression test to find
>> out whether the  serialization page ever fails.
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Montag, 20. Januar 2014 03:45
>> To: Lindenmaier, Goetz; Vladimir Kozlov
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
>> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>>
>> On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I had a look at the first part of this issue: Whether StoreStore
>>> is necessary in the interpreter.  Let's for now assume the serialization
>>> page mechanism works on PPC.
>>>
>>> In the state transition leaving the VM state, which is executed in the
>>> destructor, ThreadStateTransition::transition() is called, which executes
>>>          if (UseMembar) {
>>>            OrderAccess::fence();
>>>          } else {
>>>            os::write_memory_serialize_page(thread);
>>>          }
>>>
>>> os:: write_memory_serialize_page() can not be considered a proper
>>> MemBar, as it only serializes if another thread poisoned the page.
>>> Thus it does not qualify to order the initialization and the publishing
>>> of the object.
>>>
>>> You are right, if UseMembar is true, the StoreStore in the interpreter
>>> is superfluous.  We could guard the StoreStores in the interpreter by
>>> !UseMembar.
>>
>> My understanding, from our existing non-TSO system ports, is that the
>> present assumption is that either:
>>
>> a) you have a TSO system, in which case you are probably using the
>> serialization page, but you don't need any barrier to enforce ordering
>> anyway; or
>>
>> b) you don't have a TSO system, you are using UseMembar==true and so you
>> get a full fence inserted that enforces the ordering anyway.
>>
>> So the ordering requirements are satisfied by piggy-backing on the
>> UseMembar setting that comes from the thread state transition code,
>> which forms part of the "runtime entry" code. That's not to say that you
>> will necessarily find this applied consistently in all places where it
>> might be applied - nor will you necessarily find that this is common
>> knowledge amongst VM engineers.
>>
>> Technically the storeStore barriers could be conditional on !UseMembar
>> but that is redundant in the current usage.
>>
>>> But then again, one is to order the publishing of the thread states,
>>> the other to enforce some Java semantics.  I don't know whether everybody
>>> who changes in one place is aware of both issues.  But if you want to,
>>> I'll add a !UseMembar in the interpreter.
>>
>> Here are my preferred options in order:
>>
>> 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers -
>> rely on the piggy-backing effect.
>>
>> 2. Conditionalize the new storeStore barriers on !UseMembar. This
>> unfortunately penalizes all platforms with a runtime check.
>>
>> 3. Add the storeStores unconditionally. This penalizes platforms that
>> set UseMembar==true as we will now get two fences at runtime.
>>
>> I know we're talking about the interpreter here so performance is not
>> exactly critical, but still ...
>>
>>> Maybe it would be a good idea
>>> to document the double use in interfaceSupport.cpp, too.  And maybe
>>> add an assertion of some kind.
>>
>> interfaceSupport doesn't know that other code piggy-backs on the fact
>> state-transitions have full fences when UseMembar is true. If it is
>> documented anywhere it should be in the interpreter (and any other
>> places that makes the same assumption) - something like:
>>
>> // On non-TSO systems there can be additional ordering constraints
>> // between Java-level actions (such as allocation and constructor
>> // invocation) that in principle need explicit memory barriers.
>> // However, on many non-TSO systems the thread-state transition logic
>> // in the IRT_ENTRY code will insert a full fence due to the use of
>> // UseMembar==true, which provides the necessary ordering guarantees.
>>
>>>
>>> We're digging into the other issue currenty, whether the serialization page
>>> works on ppc.  We understand your concerns and have no simple answer to
>>> it right now.  At least, in our VM and in the port there are no known problems
>>> with the state transitions.
>>
>> Even if the memory serialization page does not work, in a guaranteed
>> sense, on PPC-AIX, it is extremely unlikely that testing would expose
>> this. Also note that the memory serialization page behaviour is more a
>> function of the OS - so it may be that AIX is different to linux in that
>> regard.
>>
>> Cheers,
>> David
>> -----
>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Donnerstag, 16. Januar 2014 19:16
>>> To: David Holmes; Lindenmaier, Goetz
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers'
>>> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
>>>
>>> Changes are in C++ Interpreter so it does not affect Oracle VM.
>>> But David has point here. I would like to hear the explanation too.
>>>
>>> BTW, I see that for ppc64:
>>>
>>> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>>>
>>> as result write_memory_serialize_page() is used in
>>> ThreadStateTransition::transition().
>>>
>>> Is it not enough on PPC64?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 1/15/14 9:30 PM, David Holmes wrote:
>>>> Can I get some response on this please - specifically the redundancy wrt
>>>> IRT_ENTRY actions.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 20/12/2013 11:55 AM, David Holmes wrote:
>>>>> Still catching up ...
>>>>>
>>>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this change adds StoreStore barriers after object initialization and
>>>>>> after constructor calls in the C++ interpreter.  This assures no
>>>>>> uninitialized
>>>>>> objects or final fields are visible.
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>>>>>
>>>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
>>>>> thread state transitions that already include a full "fence" so the
>>>>> storestore barriers are redundant in those cases.
>>>>>
>>>>> The fastpath _new storestore seems okay.
>>>>>
>>>>> I don't know how handle_return gets used to know if it is reasonable or
>>>>> not.
>>>>>
>>>>> I was trying, unsuccessfully, to examine the same code in the
>>>>> templateInterpreter to see how it handles these cases as it naturally
>>>>> has the same object-initialization-safety requirements (though these can
>>>>> be handled in a number of different ways other than an unconditional
>>>>> storestore barrier at the end of the initialization and construction
>>>>> phases.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Please review and test this change.
>>>>>>
>>>>>> Best regards,
>>>>>>       Goetz.
>>>>>>

From david.holmes at oracle.com  Wed Jan 22 22:10:55 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2014 16:10:55 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<52B3CE56.9030205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>	<52DDFD9D.3050205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>	<52DE5FB0.5000808@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>	<52DED1D2.1070203@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>	<52DFF98C.8010001@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E0B26F.1000105@oracle.com>

On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
>> Yes, I will backport it.
> That's good, thank you!
>
>> I will build bundles and give them to SQE for final testing.
> __final__   That's even better, that's great!!!

Hmmm I still have reservations concerning the _thread_state changes that 
were pushed.

David
-----

> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Mittwoch, 22. Januar 2014 18:02
> To: Lindenmaier, Goetz
> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>
> Hi Goetz
>
> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>> Thanks for testing and pushing!
>>
>> Will you push this also to stage?  I assume we can handle this
>> as the other three hotspot changes, without a new bug-id?
>
> Yes, I will backport it.
>
> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581?
> Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix
> from jdk9. Or I am mistaking?
>
>>
>> Also, when do you think we (you unfortunately) should update
>> the repos again?  Stage-9 maybe after Volkers last change is submitted?
>
> After I test and push 8031581 I will do sync with latest jdk9 sources (b01).
> I will build bundles and give them to SQE for final testing.
>
> Thanks,
> Vladimir
>
>>
>> Best regards,
>>     Goetz
>>
>>
>>
>> -----Original Message-----
>> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
>> Sent: Dienstag, 21. Januar 2014 21:00
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Thanks. I am pushing it.
>>
>> Vladimir
>>
>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>>> Sorry, I missed that.  fixed.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Dienstag, 21. Januar 2014 12:53
>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Thanks Goetz!
>>>
>>> This typo still exists:
>>>
>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>
>>> s/final/volatile/
>>>
>>> Otherwise no further comments from me.
>>>
>>> David
>>>
>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I made a new webrev
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>>> differing from
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>> only in the comments.
>>>>
>>>> I removed
>>>> // Support ordering of "Independent Reads of Independent Writes".
>>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>>> files.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Dienstag, 21. Januar 2014 05:55
>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I tried to come up with a webrev that implements the change as proposed in
>>>>> your mails:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>>
>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>>
>>>> Given the flag name the commentary eg:
>>>>
>>>> +       // Support ordering of "Independent Reads of Independent Writes".
>>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>>
>>>> seems somewhat redundant.
>>>>
>>>>> I left the definition and handling of _wrote_volatile in the code, without
>>>>> any protection.
>>>>
>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>
>>>> s/final/volatile
>>>>
>>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>>>> and put it on one line.
>>>>>
>>>>> I removed the comment in library_call.cpp.
>>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>>>> from the comments as it's PPC specific.
>>>>
>>>> I think the primary IRIW comment/explanation should go in
>>>> globalDefinitions.hpp where
>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>>
>>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>>>> issues in C1 if nobody did it by then.
>>>>
>>>> I've filed:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>>
>>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>>>> platforms"
>>>>
>>>> to cover this task, as it may be needed sooner rather than later.
>>>>
>>>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>>>
>>>> Ok.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>>> To: Vladimir Kozlov
>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>>> parse.hpp.
>>>>>>>>
>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>>
>>>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>>>> have this as a build-time construct rather than a
>>>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>>>> use it.
>>>>>>
>>>>>> Any decent C++ compiler will optimize expressions with such constants
>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>>>
>>>>> If you insist then we may as well do it all the same way. Better to be
>>>>> consistent.
>>>>>
>>>>> My apologies Goetz for wasting your time going back and forth on this.
>>>>>
>>>>> That aside I have a further concern with this IRIW support - it is
>>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>>>> this is going on then we (which probably means the Oracle 'we') need to
>>>>> add the missing C1 code.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>>> #else
>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>>
>>>>>>>> and then:
>>>>>>>>
>>>>>>>>        #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>>          oop p = JNIHandles::resolve(obj); \
>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>>> OrderAccess::fence(); \
>>>>>>>>          volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>>
>>>>>>>> And:
>>>>>>>>
>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>>> field->is_volatile()) {
>>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>>> +  }
>>>>>>>>
>>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>>>
>>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>>
>>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>>> method()->is_initializer()) )) {
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> I updated the webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>
>>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>>         reflect the new flagging.  Also I mention that we support the
>>>>>>>>>>         volatile constructor issue, but that it's not standard.
>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>>         I also think it's better to separate these this way.
>>>>>>>>>
>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>>> please.
>>>>>>>>>
>>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>>
>>>>>>>>>           if (is_volatile) {
>>>>>>>>> !     if (!is_store) {
>>>>>>>>>               insert_mem_bar(Op_MemBarAcquire);
>>>>>>>>> !     } else {
>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile);
>>>>>>>>> + #endif
>>>>>>>>> +     }
>>>>>>>>>
>>>>>>>>> I don't think the comment is needed.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Thanks for your comments!
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>         Goetz.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>>
>>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>>>> specifically it is
>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>>>> Seems
>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>>>
>>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>>> discussed
>>>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>>>> PPC64 porters.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>>>> this version.
>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>>> To: David Holmes
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>>>> not
>>>>>>>>>>>> required to pass.
>>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>>>> worked
>>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>>>> it by
>>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>>>> part is
>>>>>>>>>>> not that performance relevant.
>>>>>>>>>>>
>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>>> think
>>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>          Goetz
>>>>>>>>>>>
>>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>>>> emails.
>>>>>>>>>>>
>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>>>> settled.
>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>>>
>>>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>>
>>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>>>> But I'm
>>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>>
>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>>>> stores.
>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>>> constructor tests.
>>>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>>>> after stores
>>>>>>>>>>>>              to pass the volatile constructor tests.
>>>>>>>>>>>
>>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>>> were not
>>>>>>>>>>> required to pass.
>>>>>>>>>>>
>>>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>>>> order
>>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>>>> The only instruction
>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>>>> therefore the
>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>>>> proper representation
>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>>>> it's pointless
>>>>>>>>>>>> anyways.
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>
>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>> think
>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>>>> Or also
>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>>
>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>>> constructor-barrier
>>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>>>> *may*
>>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>>>> ensure
>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>>> invalid
>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>>>> need it
>>>>>>>>>>>> due to other factors).
>>>>>>>>>>>>
>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>>>> term :)
>>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>>
>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>>> visible to
>>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>>> architectures
>>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>>
>>>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>>>> ARM and
>>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>>
>>>>>>>>>>>>          > The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>          > remove the sync instruction from behind stores
>>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>>          > and place it before loads.
>>>>>>>>>>>>
>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>>>> after
>>>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>>>> same
>>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>>>> load -
>>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>>>> clearer.
>>>>>>>>>>>>
>>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>>> implemented as
>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>>>> hooks
>>>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>>>> this
>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>>             OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>             VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>> or
>>>>>>>>>>>>>            OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>>>> store
>>>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>>>> you
>>>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>>>> solution,
>>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> @David
>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>>>> used 'read'
>>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>>>> above).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>>> processors
>>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>>
>>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>             load
>>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>>> term and
>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>             The JMM is fine. And
>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>             MemBarVolatile
>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>>               LongVolatileTest
>>>>>>>>>>>>>>>               AtomicIntegerInitialValueTest
>>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>>>> account
>>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>>              MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>>>              MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>              MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>>              MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>>               MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>>              MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>>>> read
>>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>>>> few
>>>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>>>> store
>>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>>>> software
>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>>>> don't have
>>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>>>> I will
>>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             From what I understand what we see here is an attempt to
>>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>>             From what I understand our ppc port is also affected.
>>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                if (is_vol) {
>>>>>>>>>>>>>>>>                  // See comment in do_get_xxx().
>>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>>                  insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>>                  if (is_field) {
>>>>>>>>>>>>>>>>                    // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>>                    set_wrote_volatile(true);
>>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>>               __________    __________    __________    __________
>>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>>>                              read(y)                     read(x)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>               Goetz.
>>>>>>>>>>>>>>>>>

From david.holmes at oracle.com  Wed Jan 22 22:24:45 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2014 16:24:45 +1000
Subject: Which optimizations does Hotspot apply?
In-Reply-To: <52E05640.3020000@univ-mlv.fr>
References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de>
	<52E05640.3020000@univ-mlv.fr>
Message-ID: <52E0B5AD.8070601@oracle.com>

Hotspot questions belong on hotspot lists. cc'ing hotspot-dev and 
(trying to) bcc core-libs-dev.

David

On 23/01/2014 9:37 AM, Remi Forax wrote:
> On 01/22/2014 11:37 PM, Robert Stupp wrote:
>> Is there any documentation available which optimizations Hotspot can
>> perform and what "collecting a garbage" object costs?
>> I know that these are two completely different areas ;)
>>
>> I was inspecting whether the following code
>>      for (Object o : someArrayList) { ... }
>> would be faster than
>>      for (int i=0, l=someArrayList.size(); i<l; i++) { Object
>> o=someArrayList.get(i); }
>> for RandomAccessList implementations. The challenge here is not just
>> to track the CPU time spent creating & using the iterator vs. size() &
>> get() calls but also track GC effort (which is at least complicated if
>> not impossible due to the variety of GC configuration options).
>
> For a long time, using a for with an index (if you are *sure* that it's
> an ArrayList) was faster.
> With latest jdk8, it's not true anymore.
> (and most of the time the iterator object is not created anymore at
> least with jdk7+).
>
>>
>> For example:
>> - Does it help Hotspot to declare parameters/variables as "final" or
>> can Hotspot identify that?
>
> no, it's an urban myth.
> You can test it by yourself, if you declare a local variable final or
> not the exact same bytecode is produced by javac. The keyword final for
> a local variable (or a parameter) is not stored in the bytecode.
>
> BTW, final was introduced in 1.1 mostly to allow to capture the value of
> a variable to be used by an anonymous class, Java 8 doesn't require this
> kind of variable to be declared final anymore.
>
>> - When does Hotspot inline method calls in general and getters/setters
>> especially?
>
> In general, up to a depth of 10 by default and 1 for a recursive method.
> Roughly, a method call is not inlined either if the call is virtual and
> can call too many implementations or if the generated assembly code will
> be too big.
>
>>
>> I think such a piece of documentation (just what Hotspot can do in
>> which release) would be really helpful when someone tries to optimize
>> code - want to say: the question is: "Is something worth to spend time
>> on or is this special situation handled by Hotspot?"
>
> It never worth it.
> Choose the right algorithms and shape your data to be easily consumed by
> your algorithms is enough.
>
>>
>> -Robert
>
> R?mi
>

From vladimir.kozlov at oracle.com  Wed Jan 22 22:55:57 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Jan 2014 22:55:57 -0800
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52E0B26F.1000105@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>	<52DDFD9D.3050205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>	<52DE5FB0.5000808@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>	<52DED1D2.1070203@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>	<52DFF98C.8010001@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap>
	<52E0B26F.1000105@oracle.com>
Message-ID: <52E0BCFD.8020202@oracle.com>

Okay, lets resolve it.

David, are you talking about this change?:

http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/diff/3205e78d8193/src/share/vm/runtime/thread.hpp

Which may penalize our binaries without need. I think Goetz suggested already to put it under #ifdef PPC64 but  I may be 
misremember. Would #ifdef solution satisfy you?

Thanks,
Vladimir

On 1/22/14 10:10 PM, David Holmes wrote:
> On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>>> Yes, I will backport it.
>> That's good, thank you!
>>
>>> I will build bundles and give them to SQE for final testing.
>> __final__   That's even better, that's great!!!
>
> Hmmm I still have reservations concerning the _thread_state changes that were pushed.
>
> David
> -----
>
>> Best regards,
>>    Goetz.
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 22. Januar 2014 18:02
>> To: Lindenmaier, Goetz
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz
>>
>> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>>
>>> Thanks for testing and pushing!
>>>
>>> Will you push this also to stage?  I assume we can handle this
>>> as the other three hotspot changes, without a new bug-id?
>>
>> Yes, I will backport it.
>>
>> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581?
>> Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix
>> from jdk9. Or I am mistaking?
>>
>>>
>>> Also, when do you think we (you unfortunately) should update
>>> the repos again?  Stage-9 maybe after Volkers last change is submitted?
>>
>> After I test and push 8031581 I will do sync with latest jdk9 sources (b01).
>> I will build bundles and give them to SQE for final testing.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Best regards,
>>>     Goetz
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
>>> Sent: Dienstag, 21. Januar 2014 21:00
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Thanks. I am pushing it.
>>>
>>> Vladimir
>>>
>>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>>>> Sorry, I missed that.  fixed.
>>>>
>>>> Best regards,
>>>>      Goetz.
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Dienstag, 21. Januar 2014 12:53
>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Thanks Goetz!
>>>>
>>>> This typo still exists:
>>>>
>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>
>>>> s/final/volatile/
>>>>
>>>> Otherwise no further comments from me.
>>>>
>>>> David
>>>>
>>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I made a new webrev
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>>>> differing from
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>> only in the comments.
>>>>>
>>>>> I removed
>>>>> // Support ordering of "Independent Reads of Independent Writes".
>>>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>>>> files.
>>>>>
>>>>> Best regards,
>>>>>       Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Dienstag, 21. Januar 2014 05:55
>>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I tried to come up with a webrev that implements the change as proposed in
>>>>>> your mails:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>>>
>>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>>>
>>>>> Given the flag name the commentary eg:
>>>>>
>>>>> +       // Support ordering of "Independent Reads of Independent Writes".
>>>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>>>
>>>>> seems somewhat redundant.
>>>>>
>>>>>> I left the definition and handling of _wrote_volatile in the code, without
>>>>>> any protection.
>>>>>
>>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>>
>>>>> s/final/volatile
>>>>>
>>>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>>>>> and put it on one line.
>>>>>>
>>>>>> I removed the comment in library_call.cpp.
>>>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>>>>> from the comments as it's PPC specific.
>>>>>
>>>>> I think the primary IRIW comment/explanation should go in
>>>>> globalDefinitions.hpp where
>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>>>
>>>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>>>>> issues in C1 if nobody did it by then.
>>>>>
>>>>> I've filed:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>>>
>>>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>>>>> platforms"
>>>>>
>>>>> to cover this task, as it may be needed sooner rather than later.
>>>>>
>>>>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>>>>
>>>>> Ok.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Best regards,
>>>>>>        Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>>>> To: Vladimir Kozlov
>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>>
>>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>>>> parse.hpp.
>>>>>>>>>
>>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>>>
>>>>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>>>>> have this as a build-time construct rather than a
>>>>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>>>>> use it.
>>>>>>>
>>>>>>> Any decent C++ compiler will optimize expressions with such constants
>>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>>>>
>>>>>> If you insist then we may as well do it all the same way. Better to be
>>>>>> consistent.
>>>>>>
>>>>>> My apologies Goetz for wasting your time going back and forth on this.
>>>>>>
>>>>>> That aside I have a further concern with this IRIW support - it is
>>>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>>>>> this is going on then we (which probably means the Oracle 'we') need to
>>>>>> add the missing C1 code.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Vladimir
>>>>>>>
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>>>> #else
>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>>>> #endif
>>>>>>>>>
>>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>>>
>>>>>>>>> and then:
>>>>>>>>>
>>>>>>>>>        #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>>>          oop p = JNIHandles::resolve(obj); \
>>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>>>> OrderAccess::fence(); \
>>>>>>>>>          volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>>>
>>>>>>>>> And:
>>>>>>>>>
>>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>>>> field->is_volatile()) {
>>>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>>>> +  }
>>>>>>>>>
>>>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>>>>
>>>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>>>
>>>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>>>> method()->is_initializer()) )) {
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> I updated the webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>
>>>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>>>         reflect the new flagging.  Also I mention that we support the
>>>>>>>>>>>         volatile constructor issue, but that it's not standard.
>>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>>>         I also think it's better to separate these this way.
>>>>>>>>>>
>>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>>>> please.
>>>>>>>>>>
>>>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>>>
>>>>>>>>>>           if (is_volatile) {
>>>>>>>>>> !     if (!is_store) {
>>>>>>>>>>               insert_mem_bar(Op_MemBarAcquire);
>>>>>>>>>> !     } else {
>>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile);
>>>>>>>>>> + #endif
>>>>>>>>>> +     }
>>>>>>>>>>
>>>>>>>>>> I don't think the comment is needed.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Thanks for your comments!
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>         Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>>>
>>>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>>>>> specifically it is
>>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>>>>> Seems
>>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>>>>
>>>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>>>> discussed
>>>>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>>>>> PPC64 porters.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>>>>> this version.
>>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>>>> To: David Holmes
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>>>>> not
>>>>>>>>>>>>> required to pass.
>>>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>>>>> worked
>>>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>>>>> it by
>>>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>>>>> part is
>>>>>>>>>>>> not that performance relevant.
>>>>>>>>>>>>
>>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>>>> think
>>>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz
>>>>>>>>>>>>
>>>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>>>>> emails.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>>>>> settled.
>>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>>>>
>>>>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>>>
>>>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>>>>> But I'm
>>>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>>>
>>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>>>>> stores.
>>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>>>> constructor tests.
>>>>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>>>>> after stores
>>>>>>>>>>>>>              to pass the volatile constructor tests.
>>>>>>>>>>>>
>>>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>>>> were not
>>>>>>>>>>>> required to pass.
>>>>>>>>>>>>
>>>>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>>>>> order
>>>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>>>>> The only instruction
>>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>>>>> therefore the
>>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>>>>> proper representation
>>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>>>>> it's pointless
>>>>>>>>>>>>> anyways.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>
>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>>> think
>>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>>>>> Or also
>>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>>>> constructor-barrier
>>>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>>>>> *may*
>>>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>>>>> ensure
>>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>>>> invalid
>>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>>>>> need it
>>>>>>>>>>>>> due to other factors).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>>>>> term :)
>>>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>>>> visible to
>>>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>>>> architectures
>>>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>>>
>>>>>>>>>>>>>          > The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>>          > remove the sync instruction from behind stores
>>>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>>>          > and place it before loads.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>>>>> after
>>>>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>>>>> load -
>>>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>>>>> clearer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>>>> implemented as
>>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>>>>> hooks
>>>>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>>>>> this
>>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>>>             OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>             VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>            OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>>>>> store
>>>>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>>>>> solution,
>>>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>>>>> used 'read'
>>>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>>>>> above).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>>>> processors
>>>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>>             load
>>>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>>>> term and
>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             The JMM is fine. And
>>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>>             MemBarVolatile
>>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>>>               LongVolatileTest
>>>>>>>>>>>>>>>>               AtomicIntegerInitialValueTest
>>>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>>>>> account
>>>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>>>              MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>>>>              MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>>              MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>>>              MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>>>               MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>>>              MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>>>>> read
>>>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>>>>> store
>>>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>>>>> software
>>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>>>>> don't have
>>>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>>>>> I will
>>>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             From what I understand what we see here is an attempt to
>>>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>>>             From what I understand our ppc port is also affected.
>>>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                if (is_vol) {
>>>>>>>>>>>>>>>>>                  // See comment in do_get_xxx().
>>>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>>>                  insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>>>                  if (is_field) {
>>>>>>>>>>>>>>>>>                    // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>>>                    set_wrote_volatile(true);
>>>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>>>               __________    __________    __________    __________
>>>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>>>>                              read(y)                     read(x)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>               Goetz.
>>>>>>>>>>>>>>>>>>

From goetz.lindenmaier at sap.com  Thu Jan 23 05:33:38 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 23 Jan 2014 13:33:38 +0000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent
	Reads of Independent Writes
In-Reply-To: <52E0BCFD.8020202@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>
	<52D5DC80.1040003@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>
	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>
	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>
	<52D7A0A9.6070208@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>
	<52DDFD9D.3050205@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>
	<52DE5FB0.5000808@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>
	<52DED1D2.1070203@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>
	<52DFF98C.8010001@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap>
	<52E0B26F.1000105@oracle.com> <52E0BCFD.8020202@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F71E@DEWDFEMB12A.global.corp.sap>

Hi,

I tried to avoid #ifdefs, but for performance it makes sense to add them.
I'm fine with that.  If you agree on this, I will make a webrev.

But as I understand, on sparc and x86 that ends up being a volatile store,
so there is no big overhead (comparable to issuing a fence operation).

Best regards,
  Goetz


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Donnerstag, 23. Januar 2014 07:56
To: David Holmes; Lindenmaier, Goetz
Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Okay, lets resolve it.

David, are you talking about this change?:

http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/diff/3205e78d8193/src/share/vm/runtime/thread.hpp

Which may penalize our binaries without need. I think Goetz suggested already to put it under #ifdef PPC64 but  I may be 
misremember. Would #ifdef solution satisfy you?

Thanks,
Vladimir

On 1/22/14 10:10 PM, David Holmes wrote:
> On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>>> Yes, I will backport it.
>> That's good, thank you!
>>
>>> I will build bundles and give them to SQE for final testing.
>> __final__   That's even better, that's great!!!
>
> Hmmm I still have reservations concerning the _thread_state changes that were pushed.
>
> David
> -----
>
>> Best regards,
>>    Goetz.
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 22. Januar 2014 18:02
>> To: Lindenmaier, Goetz
>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>
>> Hi Goetz
>>
>> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>>
>>> Thanks for testing and pushing!
>>>
>>> Will you push this also to stage?  I assume we can handle this
>>> as the other three hotspot changes, without a new bug-id?
>>
>> Yes, I will backport it.
>>
>> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581?
>> Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix
>> from jdk9. Or I am mistaking?
>>
>>>
>>> Also, when do you think we (you unfortunately) should update
>>> the repos again?  Stage-9 maybe after Volkers last change is submitted?
>>
>> After I test and push 8031581 I will do sync with latest jdk9 sources (b01).
>> I will build bundles and give them to SQE for final testing.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Best regards,
>>>     Goetz
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
>>> Sent: Dienstag, 21. Januar 2014 21:00
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>
>>> Thanks. I am pushing it.
>>>
>>> Vladimir
>>>
>>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>>>> Sorry, I missed that.  fixed.
>>>>
>>>> Best regards,
>>>>      Goetz.
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Dienstag, 21. Januar 2014 12:53
>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>
>>>> Thanks Goetz!
>>>>
>>>> This typo still exists:
>>>>
>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>
>>>> s/final/volatile/
>>>>
>>>> Otherwise no further comments from me.
>>>>
>>>> David
>>>>
>>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I made a new webrev
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>>>> differing from
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>> only in the comments.
>>>>>
>>>>> I removed
>>>>> // Support ordering of "Independent Reads of Independent Writes".
>>>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>>>> files.
>>>>>
>>>>> Best regards,
>>>>>       Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Dienstag, 21. Januar 2014 05:55
>>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I tried to come up with a webrev that implements the change as proposed in
>>>>>> your mails:
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>>>
>>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>>>
>>>>> Given the flag name the commentary eg:
>>>>>
>>>>> +       // Support ordering of "Independent Reads of Independent Writes".
>>>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>>>
>>>>> seems somewhat redundant.
>>>>>
>>>>>> I left the definition and handling of _wrote_volatile in the code, without
>>>>>> any protection.
>>>>>
>>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>>
>>>>> s/final/volatile
>>>>>
>>>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() ,
>>>>>> and put it on one line.
>>>>>>
>>>>>> I removed the comment in library_call.cpp.
>>>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire."
>>>>>> from the comments as it's PPC specific.
>>>>>
>>>>> I think the primary IRIW comment/explanation should go in
>>>>> globalDefinitions.hpp where
>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>>>
>>>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task, we will fix these
>>>>>> issues in C1 if nobody did it by then.
>>>>>
>>>>> I've filed:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>>>
>>>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic
>>>>> platforms"
>>>>>
>>>>> to cover this task, as it may be needed sooner rather than later.
>>>>>
>>>>>> Wrt. to performance: Oracle will soon do heavy testing of the port.  If any
>>>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this.
>>>>>
>>>>> Ok.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Best regards,
>>>>>>        Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>>>> To: Vladimir Kozlov
>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
>>>>>>
>>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to
>>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I
>>>>>>>>> want to keep it this way, it could be useful to have such info on other
>>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>>>> parse.hpp.
>>>>>>>>>
>>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value
>>>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>>>
>>>>>>>> I asked for the ifdef some time back as I find it much preferable to
>>>>>>>> have this as a build-time construct rather than a
>>>>>>>> runtime one. I don't want to have to pay anything for this if we don't
>>>>>>>> use it.
>>>>>>>
>>>>>>> Any decent C++ compiler will optimize expressions with such constants
>>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really
>>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it.
>>>>>>
>>>>>> If you insist then we may as well do it all the same way. Better to be
>>>>>> consistent.
>>>>>>
>>>>>> My apologies Goetz for wasting your time going back and forth on this.
>>>>>>
>>>>>> That aside I have a further concern with this IRIW support - it is
>>>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If
>>>>>> this is going on then we (which probably means the Oracle 'we') need to
>>>>>> add the missing C1 code.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Vladimir
>>>>>>>
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>>>> #else
>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>>>> #endif
>>>>>>>>>
>>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>>>
>>>>>>>>> and then:
>>>>>>>>>
>>>>>>>>>        #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>>>          oop p = JNIHandles::resolve(obj); \
>>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>>>> OrderAccess::fence(); \
>>>>>>>>>          volatile type_name v = OrderAccess::load_acquire((volatile
>>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>>>
>>>>>>>>> And:
>>>>>>>>>
>>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>>>> field->is_volatile()) {
>>>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>>>> +  }
>>>>>>>>>
>>>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp
>>>>>>>>>
>>>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>>>
>>>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>>>> method()->is_initializer()) )) {
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> I updated the webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>
>>>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>>>         reflect the new flagging.  Also I mention that we support the
>>>>>>>>>>>         volatile constructor issue, but that it's not standard.
>>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>>>         I also think it's better to separate these this way.
>>>>>>>>>>
>>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>>>> please.
>>>>>>>>>>
>>>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this
>>>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>>>
>>>>>>>>>>           if (is_volatile) {
>>>>>>>>>> !     if (!is_store) {
>>>>>>>>>>               insert_mem_bar(Op_MemBarAcquire);
>>>>>>>>>> !     } else {
>>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire.
>>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile);
>>>>>>>>>> + #endif
>>>>>>>>>> +     }
>>>>>>>>>>
>>>>>>>>>> I don't think the comment is needed.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Thanks for your comments!
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>         Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>>>
>>>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay.
>>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more
>>>>>>>>>>> specifically it is
>>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of
>>>>>>>>>>> the commentary excessive, particularly for shared code. In particular
>>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the
>>>>>>>>>>> explanation and I don't think we need it to that level of detail.
>>>>>>>>>>> Seems
>>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate.
>>>>>>>>>>>
>>>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>>>> discussed
>>>>>>>>>>> are not required by the Java Memory Model. If you want to keep these
>>>>>>>>>>> then I think they should all be guarded with PPC64 because it is not
>>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the
>>>>>>>>>>> PPC64 porters.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when editing
>>>>>>>>>>>> this version.
>>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>>>> I also based the webrev on the latest version of the stage repo.
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>>>> To: David Holmes
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>>> So we can at least undo #4 now we have established those tests were
>>>>>>>>>>>>> not
>>>>>>>>>>>>> required to pass.
>>>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid that it's
>>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they
>>>>>>>>>>>> worked
>>>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I would guard
>>>>>>>>>>>> it by
>>>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.  Also, this
>>>>>>>>>>>> part is
>>>>>>>>>>>> not that performance relevant.
>>>>>>>>>>>>
>>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>>>> think
>>>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>          Goetz
>>>>>>>>>>>>
>>>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks
>>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check
>>>>>>>>>>>> emails.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this issue is
>>>>>>>>>>>>> settled.
>>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof!
>>>>>>>>>>>>>
>>>>>>>>>>>>> About our change:  David, the causality is the other way round.
>>>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>>>
>>>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>>>> implications are not nice for performance on non-TSO platforms.
>>>>>>>>>>>> But I'm
>>>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>>>
>>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after
>>>>>>>>>>>>> stores.
>>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>>>> constructor tests.
>>>>>>>>>>>>> 4. So finally we added them again at the end of the constructor
>>>>>>>>>>>>> after stores
>>>>>>>>>>>>>              to pass the volatile constructor tests.
>>>>>>>>>>>>
>>>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>>>> were not
>>>>>>>>>>>> required to pass.
>>>>>>>>>>>>
>>>>>>>>>>>>> We originally passed the constructor tests because the ppc memory
>>>>>>>>>>>>> order
>>>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as StoreLoad.
>>>>>>>>>>>>> The only instruction
>>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore,
>>>>>>>>>>>>> therefore the
>>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests.  The
>>>>>>>>>>>>> proper representation
>>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.  But now
>>>>>>>>>>>>> it's pointless
>>>>>>>>>>>>> anyways.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>
>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I
>>>>>>>>>>>> think
>>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic
>>>>>>>>>>>> based not architecture based) as that will allows for turning this
>>>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> or the like to guard the customization.  I'd like that much better.
>>>>>>>>>>>>> Or also
>>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>>>> constructor-barrier
>>>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It
>>>>>>>>>>>>> *may*
>>>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to
>>>>>>>>>>>>> ensure
>>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>>>> invalid
>>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may
>>>>>>>>>>>>> need it
>>>>>>>>>>>>> due to other factors).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the
>>>>>>>>>>>>> term :)
>>>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a
>>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>>>> visible to
>>>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>>>> architectures
>>>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is the visibility issue that I referred to and affects both
>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers
>>>>>>>>>>>>> after the stores that need to be visible. I think the crux of the
>>>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>>>
>>>>>>>>>>>>>          > The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>>          > remove the sync instruction from behind stores
>>>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>>>          > and place it before loads.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync
>>>>>>>>>>>>> after
>>>>>>>>>>>>> the store then you have to do something around the loads to get the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the
>>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the
>>>>>>>>>>>>> load -
>>>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be
>>>>>>>>>>>>> clearer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has
>>>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile
>>>>>>>>>>>>> variables. You now want to customize that but not all the requisite
>>>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>>>> implemented as
>>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post-
>>>>>>>>>>>>> hooks
>>>>>>>>>>>>> that could then be customized per platform. Otherwise you need
>>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think
>>>>>>>>>>>>> this
>>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier
>>>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>>>             OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>             VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>            OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM
>>>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But we would like to pass the torture test suite as we consider
>>>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also we think
>>>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's bad if
>>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then
>>>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fixes for the constructor issue are only needed because we
>>>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320)
>>>>>>>>>>>>>> and place it before loads.  Then there is no sync between volatile
>>>>>>>>>>>>>> store
>>>>>>>>>>>>>> and publishing the object.  So we add it again in this one case
>>>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>> And we came up with a solution we consider the best possible. If
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> have objections, you should at least give the draft of a better
>>>>>>>>>>>>>> solution,
>>>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture
>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the
>>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and
>>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen
>>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I
>>>>>>>>>>>>>> used 'read'
>>>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the method name
>>>>>>>>>>>>>> above).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>>>> processors
>>>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with
>>>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the taskqueue
>>>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been
>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.  Therefore
>>>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not
>>>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that
>>>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>>             load
>>>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>>>> term and
>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             The JMM is fine. And
>>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>>             MemBarVolatile
>>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that
>>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM
>>>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with Aleksey
>>>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>>>               LongVolatileTest
>>>>>>>>>>>>>>>>               AtomicIntegerInitialValueTest
>>>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and
>>>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is wrong.  We
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take into
>>>>>>>>>>>>>>>> account
>>>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>>>              MemBarRelease    // means LoadStore, StoreStore barrier
>>>>>>>>>>>>>>>>              MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like
>>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>>              MemBarRelease  --> membar(Assembler::LoadStore |
>>>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>>>              MemBarVolatile --> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable,
>>>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>>>               MemBarRelease --> lwsync   // Doing LoadStore,
>>>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>>>              MemBarVolatile --> sync    // // Doing LoadStore,
>>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC operations
>>>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync.  I
>>>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a comparable
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the
>>>>>>>>>>>>>>>> read
>>>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform
>>>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a
>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>> moments thought. You are implying there is a problem here that
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so
>>>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that
>>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the
>>>>>>>>>>>>>>> store
>>>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of
>>>>>>>>>>>>>>> software
>>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we
>>>>>>>>>>>>>>> don't have
>>>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days
>>>>>>>>>>>>>>> I will
>>>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so
>>>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY instead
>>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of
>>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If you wish, I
>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable
>>>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             From what I understand what we see here is an attempt to
>>>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the
>>>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make
>>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when
>>>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY
>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed
>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should
>>>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed
>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our
>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now).
>>>>>>>>>>>>>>>>> But may be it should be done using more general query which
>>>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the
>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out
>>>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM
>>>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>>>             From what I understand our ppc port is also affected.
>>>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need
>>>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                if (is_vol) {
>>>>>>>>>>>>>>>>>                  // See comment in do_get_xxx().
>>>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>>>                  insert_mem_bar(Op_MemBarVolatile); // Use fat membar
>>>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>>>                  if (is_field) {
>>>>>>>>>>>>>>>>>                    // Add MemBarRelease for constructors which write
>>>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>>>                    set_wrote_volatile(true);
>>>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>>>               __________    __________    __________    __________
>>>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                write(x=1)    read(x)       write(y=1)    read(y)
>>>>>>>>>>>>>>>>>>                              read(y)                     read(x)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This
>>>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the
>>>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store.
>>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile
>>>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets
>>>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us,
>>>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should
>>>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>               Goetz.
>>>>>>>>>>>>>>>>>>

From jesper.wilhelmsson at oracle.com  Thu Jan 23 09:45:20 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 23 Jan 2014 18:45:20 +0100
Subject: Changing lots of files - mainly GC code
In-Reply-To: <52CFEC4D.5000908@oracle.com>
References: <52CFEC4D.5000908@oracle.com>
Message-ID: <52E15530.6090402@oracle.com>

Thanks to everyone who looked at this change!
Mikael Gerdin, Thomas Schatzl, Coleen Phillmore, John Coomes, Kris Mok, and 
Vladimir Kozlov

It has been pushed to the GC repository now. I will send out a request to 
backport it to 8 to reduce the diff between 8 and 9.
/Jesper

Jesper Wilhelmsson skrev 10/1/14 1:49 PM:
> Hi,
>
> I have a change out for review that fixes a huge pile of typos in the comments
> in the GC code. The RFR was sent to the GC list, but I want to give a heads up
> in case anyone else is changing GC code and want to avoid merge conflicts.
>
> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>
>
> There are also a few files where I happened to find a few typos "by accident" in
> code that is not strictly GC code. These are:
>
> src/share/vm/memory/heap.cpp
> src/share/vm/memory/heap.hpp
> src/share/vm/memory/allocation.hpp
> src/share/vm/memory/resourceArea.hpp
> src/share/vm/runtime/thread.cpp
>
> There is a total of eight typos fixed in these files so I think the risk of
> merge conflicts here is minimal. Are there any objections to including these
> fixes in the change?
>
> Thanks,
> /Jesper

From igor.veresov at oracle.com  Thu Jan 23 11:55:22 2014
From: igor.veresov at oracle.com (igor.veresov at oracle.com)
Date: Thu, 23 Jan 2014 19:55:22 +0000
Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets
Message-ID: <20140123195526.A027E626F5@hg.openjdk.java.net>

Changeset: f970454708b8
Author:    iveresov
Date:      2014-01-17 18:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f970454708b8

8032207: C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size
Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI
Reviewed-by: kvn, azeemj

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/codegen/LoadWithMask.java

Changeset: 984401824c5e
Author:    iveresov
Date:      2014-01-21 20:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/984401824c5e

8031743: C2: loadI2L_immI broken for negative memory values
Summary: Restrict loadI2L_imm optimizations to positive values of mask
Reviewed-by: kvn, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
+ test/compiler/codegen/LoadWithMask2.java


From alejandro.murillo at oracle.com  Thu Jan 23 15:09:07 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Thu, 23 Jan 2014 23:09:07 +0000
Subject: hg: hsx/hsx25/hotspot: 8 new changesets
Message-ID: <20140123230927.1F51A62717@hg.openjdk.java.net>

Changeset: 55ff9170e27d
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/55ff9170e27d

Added tag jdk8-b125 for changeset df333ee12bba

! .hgtags

Changeset: c8218f1072a0
Author:    katleman
Date:      2014-01-22 14:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c8218f1072a0

Merge

! .hgtags

Changeset: c2106608358b
Author:    amurillo
Date:      2014-01-17 20:30 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c2106608358b

8032015: new hotspot build - hs25-b68
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 709018897c81
Author:    vlivanov
Date:      2014-01-23 01:23 +0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/709018897c81

8031695: CHA ignores default methods during analysis leading to incorrect code generation
Reviewed-by: jrose, acorn, hseigel, lfoltan

! src/share/vm/code/dependencies.cpp
+ test/compiler/inlining/DefaultAndConcreteMethodsCHA.java

Changeset: f970454708b8
Author:    iveresov
Date:      2014-01-17 18:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f970454708b8

8032207: C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size
Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI
Reviewed-by: kvn, azeemj

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/codegen/LoadWithMask.java

Changeset: 984401824c5e
Author:    iveresov
Date:      2014-01-21 20:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/984401824c5e

8031743: C2: loadI2L_immI broken for negative memory values
Summary: Restrict loadI2L_imm optimizations to positive values of mask
Reviewed-by: kvn, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
+ test/compiler/codegen/LoadWithMask2.java

Changeset: d45454002494
Author:    amurillo
Date:      2014-01-23 13:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d45454002494

Merge


Changeset: 2c564e329c87
Author:    amurillo
Date:      2014-01-23 13:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c564e329c87

Added tag hs25-b68 for changeset d45454002494

! .hgtags


From alejandro.murillo at oracle.com  Thu Jan 23 16:19:28 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 24 Jan 2014 00:19:28 +0000
Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets
Message-ID: <20140124001950.39C3862727@hg.openjdk.java.net>

Changeset: 55ff9170e27d
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/55ff9170e27d

Added tag jdk8-b125 for changeset df333ee12bba

! .hgtags

Changeset: c8218f1072a0
Author:    katleman
Date:      2014-01-22 14:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c8218f1072a0

Merge

! .hgtags

Changeset: d45454002494
Author:    amurillo
Date:      2014-01-23 13:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d45454002494

Merge


Changeset: 2c564e329c87
Author:    amurillo
Date:      2014-01-23 13:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c564e329c87

Added tag hs25-b68 for changeset d45454002494

! .hgtags

Changeset: 7e412f95e310
Author:    amurillo
Date:      2014-01-23 13:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7e412f95e310

8032608: new hotspot build - hs25-b69
Reviewed-by: jcoomes

! make/hotspot_version


From serguei.spitsyn at oracle.com  Thu Jan 23 18:10:47 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 24 Jan 2014 02:10:47 +0000
Subject: hg: hsx/jdk7u/hotspot: 5 new changesets
Message-ID: <20140124021101.C60E96272C@hg.openjdk.java.net>

Changeset: f232cfa3fef2
Author:    sspitsyn
Date:      2014-01-21 20:43 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f232cfa3fef2

7194607: VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge
Summary: Use verifier_max_size instead of max_size to get code attribute max stack size.
Reviewed-by: dcubed, minqi
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiClassFileReconstituter.cpp

Changeset: 33f4829de8eb
Author:    sspitsyn
Date:      2014-01-21 20:44 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/33f4829de8eb

8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to
Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before.
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp

Changeset: 191481960846
Author:    sspitsyn
Date:      2014-01-21 20:44 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/191481960846

8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds
Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged.
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp

Changeset: 4baf20879672
Author:    sspitsyn
Date:      2014-01-21 20:45 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4baf20879672

8006546: JSR 292: typos in the ConstantPool::copy_cp_impl()
Summary: Simple typos that need to be fixed
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/constantPoolOop.cpp

Changeset: 8816e9af562c
Author:    sspitsyn
Date:      2014-01-21 20:46 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/8816e9af562c

8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic
Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well.
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp


From david.holmes at oracle.com  Thu Jan 23 23:28:12 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jan 2014 17:28:12 +1000
Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads
	of Independent Writes
In-Reply-To: <52E0BCFD.8020202@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap>	<52D5DC80.1040003@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap>	<52D76D50.60700@oracle.com>	<52D78697.2090408@oracle.com>	<52D79982.4060100@oracle.com>	<52D79E61.1060801@oracle.com>	<52D7A0A9.6070208@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap>	<52DDFD9D.3050205@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap>	<52DE5FB0.5000808@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap>	<52DED1D2.1070203@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap>	<52DFF98C.8010001@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap>
	<52E0B26F.1000105@oracle.com> <52E0BCFD.8020202@oracle.com>
Message-ID: <52E2160C.6030300@oracle.com>

On 23/01/2014 4:55 PM, Vladimir Kozlov wrote:
> Okay, lets resolve it.
>
> David, are you talking about this change?:
>
> http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/diff/3205e78d8193/src/share/vm/runtime/thread.hpp

Yes.

> Which may penalize our binaries without need. I think Goetz suggested
> already to put it under #ifdef PPC64 but  I may be misremember. Would
> #ifdef solution satisfy you?

Based on other discussions this ties in with the use, or not, of 
UseMembar with non-TSO systems. But an ifdef PPC64 would be okay pending 
more complete resolution of these matters sometime in the future.

Thanks,
David


> Thanks,
> Vladimir
>
> On 1/22/14 10:10 PM, David Holmes wrote:
>> On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>>
>>>> Yes, I will backport it.
>>> That's good, thank you!
>>>
>>>> I will build bundles and give them to SQE for final testing.
>>> __final__   That's even better, that's great!!!
>>
>> Hmmm I still have reservations concerning the _thread_state changes
>> that were pushed.
>>
>> David
>> -----
>>
>>> Best regards,
>>>    Goetz.
>>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Mittwoch, 22. Januar 2014 18:02
>>> To: Lindenmaier, Goetz
>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>> Independent Reads of Independent Writes
>>>
>>> Hi Goetz
>>>
>>> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote:
>>>> Hi Vladimir,
>>>>
>>>> Thanks for testing and pushing!
>>>>
>>>> Will you push this also to stage?  I assume we can handle this
>>>> as the other three hotspot changes, without a new bug-id?
>>>
>>> Yes, I will backport it.
>>>
>>> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and
>>> new one from today 8031581?
>>> Should I backport all of them into 8u stage? From conversion between
>>> Volker and Alan some of them need backport a fix
>>> from jdk9. Or I am mistaking?
>>>
>>>>
>>>> Also, when do you think we (you unfortunately) should update
>>>> the repos again?  Stage-9 maybe after Volkers last change is submitted?
>>>
>>> After I test and push 8031581 I will do sync with latest jdk9 sources
>>> (b01).
>>> I will build bundles and give them to SQE for final testing.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Best regards,
>>>>     Goetz
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev-bounces at openjdk.java.net
>>>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir
>>>> Kozlov
>>>> Sent: Dienstag, 21. Januar 2014 21:00
>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>> Independent Reads of Independent Writes
>>>>
>>>> Thanks. I am pushing it.
>>>>
>>>> Vladimir
>>>>
>>>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote:
>>>>> Sorry, I missed that.  fixed.
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Dienstag, 21. Januar 2014 12:53
>>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>> 'hotspot-dev at openjdk.java.net'
>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>> Independent Reads of Independent Writes
>>>>>
>>>>> Thanks Goetz!
>>>>>
>>>>> This typo still exists:
>>>>>
>>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>>
>>>>> s/final/volatile/
>>>>>
>>>>> Otherwise no further comments from me.
>>>>>
>>>>> David
>>>>>
>>>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I made a new webrev
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/
>>>>>> differing from
>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>>> only in the comments.
>>>>>>
>>>>>> I removed
>>>>>> // Support ordering of "Independent Reads of Independent Writes".
>>>>>> everywhere, and edited the comments in the globalDefinition*.hpp
>>>>>> files.
>>>>>>
>>>>>> Best regards,
>>>>>>       Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Dienstag, 21. Januar 2014 05:55
>>>>>> To: Lindenmaier, Goetz; Vladimir Kozlov
>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>> Independent Reads of Independent Writes
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I tried to come up with a webrev that implements the change as
>>>>>>> proposed in
>>>>>>> your mails:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/
>>>>>>>
>>>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use
>>>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu.
>>>>>>
>>>>>> Given the flag name the commentary eg:
>>>>>>
>>>>>> +       // Support ordering of "Independent Reads of Independent
>>>>>> Writes".
>>>>>> +       if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>>>>>
>>>>>> seems somewhat redundant.
>>>>>>
>>>>>>> I left the definition and handling of _wrote_volatile in the
>>>>>>> code, without
>>>>>>> any protection.
>>>>>>
>>>>>> +   bool          _wrote_volatile;     // Did we write a final field?
>>>>>>
>>>>>> s/final/volatile
>>>>>>
>>>>>>> I protected issuing the barrier for volatile in constructors with
>>>>>>> PPC64_ONLY() ,
>>>>>>> and put it on one line.
>>>>>>>
>>>>>>> I removed the comment in library_call.cpp.
>>>>>>> I also removed the sentence " Solution: implement volatile read
>>>>>>> as sync-load-acquire."
>>>>>>> from the comments as it's PPC specific.
>>>>>>
>>>>>> I think the primary IRIW comment/explanation should go in
>>>>>> globalDefinitions.hpp where
>>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined.
>>>>>>
>>>>>>> Wrt. to C1: we plan to port C1 to PPC64, too.  During that task,
>>>>>>> we will fix these
>>>>>>> issues in C1 if nobody did it by then.
>>>>>>
>>>>>> I've filed:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8032366
>>>>>>
>>>>>> "Implement C1 support for IRIW conformance on
>>>>>> non-multiple-copy-atomic
>>>>>> platforms"
>>>>>>
>>>>>> to cover this task, as it may be needed sooner rather than later.
>>>>>>
>>>>>>> Wrt. to performance: Oracle will soon do heavy testing of the
>>>>>>> port.  If any
>>>>>>> performance problems arise, we still can add #ifdef PPC64 to
>>>>>>> circumvent this.
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Best regards,
>>>>>>>        Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Donnerstag, 16. Januar 2014 10:05
>>>>>>> To: Vladimir Kozlov
>>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>> Independent Reads of Independent Writes
>>>>>>>
>>>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote:
>>>>>>>> On 1/16/14 12:34 AM, David Holmes wrote:
>>>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote:
>>>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are
>>>>>>>>>> trying to
>>>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef
>>>>>>>>>> and I
>>>>>>>>>> want to keep it this way, it could be useful to have such info
>>>>>>>>>> on other
>>>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in
>>>>>>>>>> parse.hpp.
>>>>>>>>>>
>>>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp
>>>>>>>>>> define a value
>>>>>>>>>> which could be checked in all places instead of #ifdef:
>>>>>>>>>
>>>>>>>>> I asked for the ifdef some time back as I find it much
>>>>>>>>> preferable to
>>>>>>>>> have this as a build-time construct rather than a
>>>>>>>>> runtime one. I don't want to have to pay anything for this if
>>>>>>>>> we don't
>>>>>>>>> use it.
>>>>>>>>
>>>>>>>> Any decent C++ compiler will optimize expressions with such
>>>>>>>> constants
>>>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I
>>>>>>>> really
>>>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live
>>>>>>>> with it.
>>>>>>>
>>>>>>> If you insist then we may as well do it all the same way. Better
>>>>>>> to be
>>>>>>> consistent.
>>>>>>>
>>>>>>> My apologies Goetz for wasting your time going back and forth on
>>>>>>> this.
>>>>>>>
>>>>>>> That aside I have a further concern with this IRIW support - it is
>>>>>>> incomplete as there is no C1 support, as PPC64 isn't using
>>>>>>> client. If
>>>>>>> this is going on then we (which probably means the Oracle 'we')
>>>>>>> need to
>>>>>>> add the missing C1 code.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
>>>>>>>>>> #else
>>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false;
>>>>>>>>>> #endif
>>>>>>>>>>
>>>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever
>>>>>>>>>>
>>>>>>>>>> and then:
>>>>>>>>>>
>>>>>>>>>>        #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>>>>>>>>>>          oop p = JNIHandles::resolve(obj); \
>>>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu)
>>>>>>>>>> OrderAccess::fence(); \
>>>>>>>>>>          volatile type_name v =
>>>>>>>>>> OrderAccess::load_acquire((volatile
>>>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset));
>>>>>>>>>>
>>>>>>>>>> And:
>>>>>>>>>>
>>>>>>>>>> +  if (support_IRIW_for_not_multiple_copy_atomic_cpu &&
>>>>>>>>>> field->is_volatile()) {
>>>>>>>>>> +    insert_mem_bar(Op_MemBarVolatile);   // StoreLoad barrier
>>>>>>>>>> +  }
>>>>>>>>>>
>>>>>>>>>> And so on. The comments will be needed only in
>>>>>>>>>> globalDefinitions.hpp
>>>>>>>>>>
>>>>>>>>>> The code in parse1.cpp could be put on one line:
>>>>>>>>>>
>>>>>>>>>> +  if (wrote_final() PPC64_ONLY( || (wrote_volatile() &&
>>>>>>>>>> method()->is_initializer()) )) {
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote:
>>>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> I updated the webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>>
>>>>>>>>>>>> - I removed the IRIW example in parse3.cpp
>>>>>>>>>>>> - I adapted the comments not to point to that comment, and to
>>>>>>>>>>>>         reflect the new flagging.  Also I mention that we
>>>>>>>>>>>> support the
>>>>>>>>>>>>         volatile constructor issue, but that it's not standard.
>>>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64.
>>>>>>>>>>>>         I also think it's better to separate these this way.
>>>>>>>>>>>
>>>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field
>>>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too
>>>>>>>>>>> please.
>>>>>>>>>>>
>>>>>>>>>>> One nit I missed before. In
>>>>>>>>>>> src/share/vm/opto/library_call.cpp this
>>>>>>>>>>> comment doesn't make much sense to me and refers to
>>>>>>>>>>> ppc specific stuff in a shared file:
>>>>>>>>>>>
>>>>>>>>>>>           if (is_volatile) {
>>>>>>>>>>> !     if (!is_store) {
>>>>>>>>>>>               insert_mem_bar(Op_MemBarAcquire);
>>>>>>>>>>> !     } else {
>>>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC
>>>>>>>>>>> !       // Changed volatiles/Unsafe: lwsync-store,
>>>>>>>>>>> sync-load-acquire.
>>>>>>>>>>>               insert_mem_bar(Op_MemBarVolatile);
>>>>>>>>>>> + #endif
>>>>>>>>>>> +     }
>>>>>>>>>>>
>>>>>>>>>>> I don't think the comment is needed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your comments!
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>         Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net';
>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'
>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry for the delay in getting back to this.
>>>>>>>>>>>>
>>>>>>>>>>>> The general changes to the volatile barriers to support IRIW
>>>>>>>>>>>> are okay.
>>>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this
>>>>>>>>>>>> (though more
>>>>>>>>>>>> specifically it is
>>>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I
>>>>>>>>>>>> find much of
>>>>>>>>>>>> the commentary excessive, particularly for shared code. In
>>>>>>>>>>>> particular
>>>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to
>>>>>>>>>>>> give the
>>>>>>>>>>>> explanation and I don't think we need it to that level of
>>>>>>>>>>>> detail.
>>>>>>>>>>>> Seems
>>>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite
>>>>>>>>>>>> adequate.
>>>>>>>>>>>>
>>>>>>>>>>>> The changes related to volatile writes in the constructor, as
>>>>>>>>>>>> discussed
>>>>>>>>>>>> are not required by the Java Memory Model. If you want to
>>>>>>>>>>>> keep these
>>>>>>>>>>>> then I think they should all be guarded with PPC64 because
>>>>>>>>>>>> it is not
>>>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being
>>>>>>>>>>>> made by the
>>>>>>>>>>>> PPC64 porters.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I updated this webrev.  I detected a small flaw I made when
>>>>>>>>>>>>> editing
>>>>>>>>>>>>> this version.
>>>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line.
>>>>>>>>>>>>> I also based the webrev on the latest version of the stage
>>>>>>>>>>>>> repo.
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>          Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Lindenmaier, Goetz
>>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47
>>>>>>>>>>>>> To: David Holmes
>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So we can at least undo #4 now we have established those
>>>>>>>>>>>>>> tests were
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> required to pass.
>>>>>>>>>>>>> We would prefer if we could keep this in.  We want to avoid
>>>>>>>>>>>>> that it's
>>>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after
>>>>>>>>>>>>> they
>>>>>>>>>>>>> worked
>>>>>>>>>>>>> on x86.  To clearly mark it as overfulfilling the spec I
>>>>>>>>>>>>> would guard
>>>>>>>>>>>>> it by
>>>>>>>>>>>>> a flag as proposed.  But if you insist I will remove it.
>>>>>>>>>>>>> Also, this
>>>>>>>>>>>>> part is
>>>>>>>>>>>>> not that performance relevant.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a
>>>>>>>>>>>>>> runtime one I
>>>>>>>>>>>>>> think
>>>>>>>>>>>>> I added a compile-time guard in this new webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/
>>>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC.  This introduces
>>>>>>>>>>>>> several double negations I don't like, (#ifNdef
>>>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC)
>>>>>>>>>>>>> but this way I only have to change the ppc platform.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>          Goetz
>>>>>>>>>>>>>
>>>>>>>>>>>>> P.S.:  I will also be available over the Christmas period.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58
>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two
>>>>>>>>>>>>> weeks
>>>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue
>>>>>>>>>>>>> to check
>>>>>>>>>>>>> emails.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ok, I understand the tests are wrong.  It's good this
>>>>>>>>>>>>>> issue is
>>>>>>>>>>>>>> settled.
>>>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of
>>>>>>>>>>>>>> the proof!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About our change:  David, the causality is the other way
>>>>>>>>>>>>>> round.
>>>>>>>>>>>>>> The change is about IRIW.
>>>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is the part I still have some question marks over as the
>>>>>>>>>>>>> implications are not nice for performance on non-TSO
>>>>>>>>>>>>> platforms.
>>>>>>>>>>>>> But I'm
>>>>>>>>>>>>> no further along in processing that paper I'm afraid.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them
>>>>>>>>>>>>>> after
>>>>>>>>>>>>>> stores.
>>>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile
>>>>>>>>>>>>>> constructor tests.
>>>>>>>>>>>>>> 4. So finally we added them again at the end of the
>>>>>>>>>>>>>> constructor
>>>>>>>>>>>>>> after stores
>>>>>>>>>>>>>>              to pass the volatile constructor tests.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So we can at least undo #4 now we have established those tests
>>>>>>>>>>>>> were not
>>>>>>>>>>>>> required to pass.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> We originally passed the constructor tests because the ppc
>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>> order
>>>>>>>>>>>>>> instructions are not as find-granular as the
>>>>>>>>>>>>>> operations in the IR.  MemBarVolatile is specified as
>>>>>>>>>>>>>> StoreLoad.
>>>>>>>>>>>>>> The only instruction
>>>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does
>>>>>>>>>>>>>> StoreStore,
>>>>>>>>>>>>>> therefore the
>>>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor
>>>>>>>>>>>>>> tests.  The
>>>>>>>>>>>>>> proper representation
>>>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore.
>>>>>>>>>>>>>> But now
>>>>>>>>>>>>>> it's pointless
>>>>>>>>>>>>>> anyways.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it.
>>>>>>>>>>>>>> I'd be happy to add a property
>>>>>>>>>>>>>>           OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>>
>>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime
>>>>>>>>>>>>> one I
>>>>>>>>>>>>> think
>>>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization
>>>>>>>>>>>>> (something semantic
>>>>>>>>>>>>> based not architecture based) as that will allows for
>>>>>>>>>>>>> turning this
>>>>>>>>>>>>> on/off for any architecture for testing purposes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>> or the like to guard the customization.  I'd like that
>>>>>>>>>>>>>> much better.
>>>>>>>>>>>>>> Or also
>>>>>>>>>>>>>>            OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>            VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>           Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34
>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TL;DR version:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a
>>>>>>>>>>>>>> constructor-barrier
>>>>>>>>>>>>>> for volatiles is not required as part of the JMM
>>>>>>>>>>>>>> specification. It
>>>>>>>>>>>>>> *may*
>>>>>>>>>>>>>> be required in an implementation that doesn't pre-zero
>>>>>>>>>>>>>> memory to
>>>>>>>>>>>>>> ensure
>>>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are
>>>>>>>>>>>>>> invalid
>>>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64
>>>>>>>>>>>>>> may
>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>> due to other factors).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for
>>>>>>>>>>>>>> correcting the
>>>>>>>>>>>>>> term :)
>>>>>>>>>>>>>> Second thanks for the reference to that paper! For reference:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of
>>>>>>>>>>>>>> buffers and a
>>>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes
>>>>>>>>>>>>>> visible to
>>>>>>>>>>>>>> all other hardware threads at the same time point; these
>>>>>>>>>>>>>> architectures
>>>>>>>>>>>>>> are not multiple-copy atomic."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is the visibility issue that I referred to and
>>>>>>>>>>>>>> affects both
>>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>>> PPC. But of course it is normally handled by using
>>>>>>>>>>>>>> suitable barriers
>>>>>>>>>>>>>> after the stores that need to be visible. I think the crux
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> current issue is what you wrote below:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          > The fixes for the constructor issue are only
>>>>>>>>>>>>>> needed because we
>>>>>>>>>>>>>>          > remove the sync instruction from behind stores
>>>>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>>>>          > and place it before loads.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do
>>>>>>>>>>>>>> the sync
>>>>>>>>>>>>>> after
>>>>>>>>>>>>>> the store then you have to do something around the loads
>>>>>>>>>>>>>> to get the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> results! I still don't know what lead you to the
>>>>>>>>>>>>>> conclusion that the
>>>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> load -
>>>>>>>>>>>>>> maybe when I get the chance to read that paper in full it
>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>> clearer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So ... the basic problem is that the current structure in
>>>>>>>>>>>>>> the VM has
>>>>>>>>>>>>>> hard-wired one choice of how to get the right semantics
>>>>>>>>>>>>>> for volatile
>>>>>>>>>>>>>> variables. You now want to customize that but not all the
>>>>>>>>>>>>>> requisite
>>>>>>>>>>>>>> hooks are present. It would be better if volatile_load and
>>>>>>>>>>>>>> volatile_store were factored out so that they could be
>>>>>>>>>>>>>> implemented as
>>>>>>>>>>>>>> desired per-platform. Alternatively there could be pre-
>>>>>>>>>>>>>> and post-
>>>>>>>>>>>>>> hooks
>>>>>>>>>>>>>> that could then be customized per platform. Otherwise you
>>>>>>>>>>>>>> need
>>>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block
>>>>>>>>>>>>>> it. I think
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM.
>>>>>>>>>>>>>> The barrier
>>>>>>>>>>>>>> abstractions are a confused mess in my opinion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by
>>>>>>>>>>>>>>> Vladimir:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I did not yet add the
>>>>>>>>>>>>>>>             OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>             VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>            OrderAccess::cpu_is_multiple_copy_atomic()
>>>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation
>>>>>>>>>>>>>>> of the JMM
>>>>>>>>>>>>>>> I feel not in the position to contribute substantially.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But we would like to pass the torture test suite as we
>>>>>>>>>>>>>>> consider
>>>>>>>>>>>>>>> this a substantial task in implementing a PPC port.  Also
>>>>>>>>>>>>>>> we think
>>>>>>>>>>>>>>> both tests show behavior a programmer would expect.  It's
>>>>>>>>>>>>>>> bad if
>>>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> fails on ppc.  This will always first be blamed on the VM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fixes for the constructor issue are only needed
>>>>>>>>>>>>>>> because we
>>>>>>>>>>>>>>> remove the sync instruction from behind stores
>>>>>>>>>>>>>>> (parse3.cpp:320)
>>>>>>>>>>>>>>> and place it before loads.  Then there is no sync between
>>>>>>>>>>>>>>> volatile
>>>>>>>>>>>>>>> store
>>>>>>>>>>>>>>> and publishing the object.  So we add it again in this
>>>>>>>>>>>>>>> one case
>>>>>>>>>>>>>>> (volatile store in constructor).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>>>>> taskqueue problem yet,
>>>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly
>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>>> That's not true, we did a lot of investigation and
>>>>>>>>>>>>>>> testing on this
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>> And we came up with a solution we consider the best
>>>>>>>>>>>>>>> possible. If
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> have objections, you should at least give the draft of a
>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>> solution,
>>>>>>>>>>>>>>> we would volunteer to implement and test it.
>>>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency
>>>>>>>>>>>>>>> torture
>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @David
>>>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with
>>>>>>>>>>>>>>>> the term
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> ARM and
>>>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit
>>>>>>>>>>>>>>> Sarkar and
>>>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient
>>>>>>>>>>>>>>> Work-Stealing for
>>>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert
>>>>>>>>>>>>>>> Cohen
>>>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the
>>>>>>>>>>>>>>> taskqueue problem.
>>>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy
>>>>>>>>>>>>>>> atomicity, I
>>>>>>>>>>>>>>> used 'read'
>>>>>>>>>>>>>>> instead.  Sorry for that.  (I also fixed that in the
>>>>>>>>>>>>>>> method name
>>>>>>>>>>>>>>> above).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards and thanks for all your involvements,
>>>>>>>>>>>>>>>            Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53
>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- Volatile in constuctor
>>>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a
>>>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32
>>>>>>>>>>>>>>>> processors
>>>>>>>>>>>>>>>> and are Power 5-7.  But see also Aleksey's mail.  (Thanks
>>>>>>>>>>>>>>>> Aleksey!)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And see follow ups - the tests are invalid.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- IRIW issue
>>>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of
>>>>>>>>>>>>>>>>> detail with
>>>>>>>>>>>>>>>>> a few
>>>>>>>>>>>>>>>>> moments thought.
>>>>>>>>>>>>>>>> Sure.  There also is no solution as you require for the
>>>>>>>>>>>>>>>> taskqueue
>>>>>>>>>>>>>>>> problem yet,
>>>>>>>>>>>>>>>> and that's being discussed now for almost a year.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly
>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>> continuous.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are implying there is a problem here that will
>>>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why
>>>>>>>>>>>>>>>>> ppc is so
>>>>>>>>>>>>>>>>> different?)
>>>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'.
>>>>>>>>>>>>>>>> Therefore
>>>>>>>>>>>>>>>> I contributed a
>>>>>>>>>>>>>>>> solution with the #defines, and that's correct for all,
>>>>>>>>>>>>>>>> but not
>>>>>>>>>>>>>>>> nice, I admit.
>>>>>>>>>>>>>>>> (I don't really know about ARM, though).
>>>>>>>>>>>>>>>> So if I can write down a nicer solution testing for
>>>>>>>>>>>>>>>> methods that
>>>>>>>>>>>>>>>> are evaluated
>>>>>>>>>>>>>>>> by the C-compiler I'm happy.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the
>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>>> does not assure multiple-read-atomicity,
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>             sync
>>>>>>>>>>>>>>>>             load
>>>>>>>>>>>>>>>> does so on PPC.  And you require multiple-read-atomicity to
>>>>>>>>>>>>>>>> pass that test.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the
>>>>>>>>>>>>>>> term and
>>>>>>>>>>>>>>> can't find any reference to it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             The JMM is fine. And
>>>>>>>>>>>>>>>>             store
>>>>>>>>>>>>>>>>             MemBarVolatile
>>>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler
>>>>>>>>>>>>>>>> instructions
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> do what is required.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that
>>>>>>>>>>>>>>>> allows us to implement a correct PPC64 port.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>             Goetz.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM
>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich';
>>>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of
>>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks a lot for the detailed reviews!
>>>>>>>>>>>>>>>>> I'll try to answer to all in one mail.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't
>>>>>>>>>>>>>>>>>> guaranteed by JMM
>>>>>>>>>>>>>>>>>> to occur before the reference is assigned;
>>>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after
>>>>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>>>>> a volatile field.  Previously, we discussed this with
>>>>>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>>>>>> Shipilev
>>>>>>>>>>>>>>>>> and Doug Lea, and they agreed.
>>>>>>>>>>>>>>>>> Also, concurrency torture tests
>>>>>>>>>>>>>>>>>               LongVolatileTest
>>>>>>>>>>>>>>>>>               AtomicIntegerInitialValueTest
>>>>>>>>>>>>>>>>> will fail.
>>>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a
>>>>>>>>>>>>>>>>> volatile field would be
>>>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in
>>>>>>>>>>>>>>>>> AtomicInteger.)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The affects of unsafe publication are always surprising -
>>>>>>>>>>>>>>>> volatiles do
>>>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in
>>>>>>>>>>>>>>>> the JMM
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> Aleksey
>>>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail
>>>>>>>>>>>>>>>> due to a
>>>>>>>>>>>>>>>> missing constructor barrier.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely
>>>>>>>>>>>>>>>>>> heavyweight
>>>>>>>>>>>>>>>>> Yes, it costs measurable performance.  But else it is
>>>>>>>>>>>>>>>>> wrong.  We
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> see a way to implement this cheaper.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct
>>>>>>>>>>>>>>>>>> OrderAccess operations
>>>>>>>>>>>>>>>>> Basically, I agree on this.  But you also have to take
>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>> account
>>>>>>>>>>>>>>>>> that due to the different memory ordering instructions on
>>>>>>>>>>>>>>>>> different platforms
>>>>>>>>>>>>>>>>> just implementing something empty is not sufficient.
>>>>>>>>>>>>>>>>> An example:
>>>>>>>>>>>>>>>>>              MemBarRelease    // means LoadStore,
>>>>>>>>>>>>>>>>> StoreStore barrier
>>>>>>>>>>>>>>>>>              MemBarVolatile    // means  StoreLoad barrier
>>>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code
>>>>>>>>>>>>>>>>> looks like
>>>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>>>              MemBarRelease  -->
>>>>>>>>>>>>>>>>> membar(Assembler::LoadStore |
>>>>>>>>>>>>>>>>> Assembler::StoreStore)
>>>>>>>>>>>>>>>>>              MemBarVolatile -->
>>>>>>>>>>>>>>>>> membar(Assembler::StoreLoad)
>>>>>>>>>>>>>>>>> Just doing what is required.
>>>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no
>>>>>>>>>>>>>>>>> comparable,
>>>>>>>>>>>>>>>>> fine grained operations:
>>>>>>>>>>>>>>>>>               MemBarRelease --> lwsync   // Doing
>>>>>>>>>>>>>>>>> LoadStore,
>>>>>>>>>>>>>>>>> StoreStore, LoadLoad
>>>>>>>>>>>>>>>>>              MemBarVolatile --> sync    // // Doing
>>>>>>>>>>>>>>>>> LoadStore,
>>>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad
>>>>>>>>>>>>>>>>> obviously, the lwsync is superfluous.  Thus, as PPC
>>>>>>>>>>>>>>>>> operations
>>>>>>>>>>>>>>>>> are more (too) powerful,
>>>>>>>>>>>>>>>>> I need an additional optimization that removes the
>>>>>>>>>>>>>>>>> lwsync.  I
>>>>>>>>>>>>>>>>> can not implement
>>>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Back to the IRIW problem.  I think here we have a
>>>>>>>>>>>>>>>>> comparable
>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence()
>>>>>>>>>>>>>>>>> before the
>>>>>>>>>>>>>>>>> read
>>>>>>>>>>>>>>>>> is inefficient on platforms that have
>>>>>>>>>>>>>>>>> multiple-read-atomicity.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I would propose to guard the code by
>>>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better
>>>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic()
>>>>>>>>>>>>>>>>> Else, David, how would you propose to implement this
>>>>>>>>>>>>>>>>> platform
>>>>>>>>>>>>>>>>> independent?
>>>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of
>>>>>>>>>>>>>>>> detail with a
>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>> moments thought. You are implying there is a problem
>>>>>>>>>>>>>>>> here that
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why
>>>>>>>>>>>>>>>> ppc is so
>>>>>>>>>>>>>>>> different?) and I can not take that on face value at the
>>>>>>>>>>>>>>>> moment. The
>>>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM
>>>>>>>>>>>>>>>> requirements for
>>>>>>>>>>>>>>>> volatile accesses is if there are global visibility
>>>>>>>>>>>>>>>> issues that
>>>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers
>>>>>>>>>>>>>>>> at the
>>>>>>>>>>>>>>>> store
>>>>>>>>>>>>>>>> would deal with that, not at the load. (This situation
>>>>>>>>>>>>>>>> reminds me
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the
>>>>>>>>>>>>>>>> use of
>>>>>>>>>>>>>>>> software
>>>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency -
>>>>>>>>>>>>>>>> but we
>>>>>>>>>>>>>>>> don't have
>>>>>>>>>>>>>>>> that on ppc!)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a
>>>>>>>>>>>>>>>> couple of days
>>>>>>>>>>>>>>>> I will
>>>>>>>>>>>>>>>> be heading out on vacation for two weeks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>              Goetz.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- Other ports:
>>>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be
>>>>>>>>>>>>>>>>> relevant, so
>>>>>>>>>>>>>>>>> it might
>>>>>>>>>>>>>>>>> not happen on small machines.  But I can use PPC_ONLY
>>>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get
>>>>>>>>>>>>>>>>> rid of
>>>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization
>>>>>>>>>>>>>>>>> I agree we should not change it in the ppc port.  If
>>>>>>>>>>>>>>>>> you wish, I
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM
>>>>>>>>>>>>>>>>> To: Vladimir Kozlov
>>>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
>>>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'
>>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211):
>>>>>>>>>>>>>>>>> ordering of
>>>>>>>>>>>>>>>>> Independent Reads of Independent Writes
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a
>>>>>>>>>>>>>>>>> reasonable
>>>>>>>>>>>>>>>>> way :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>             From what I understand what we see here is
>>>>>>>>>>>>>>>>> an attempt to
>>>>>>>>>>>>>>>>> fix an
>>>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so
>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>> IRIW
>>>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64
>>>>>>>>>>>>>>>>> is to make
>>>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a
>>>>>>>>>>>>>>>>> fence() when
>>>>>>>>>>>>>>>>> doing the
>>>>>>>>>>>>>>>>> load.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I
>>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills
>>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the
>>>>>>>>>>>>>>>>> shared code
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> allow this solution to be implemented - even with
>>>>>>>>>>>>>>>>> PPC64_ONLY
>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to
>>>>>>>>>>>>>>>>> what I said
>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be
>>>>>>>>>>>>>>>>> expressed using
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired
>>>>>>>>>>>>>>>>> properties
>>>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not
>>>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>> given architecture then the implementation in
>>>>>>>>>>>>>>>>> OrderAccess should
>>>>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>>>>> to a no-op.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are
>>>>>>>>>>>>>>>>> not needed
>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>> the JMM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not
>>>>>>>>>>>>>>>>>> change our
>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>> code for our platforms (please, do not change
>>>>>>>>>>>>>>>>>> do_exits() now).
>>>>>>>>>>>>>>>>>> But may be it should be done using more general query
>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> is set
>>>>>>>>>>>>>>>>>> depending on platform:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> or similar to what we use now:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part
>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this
>>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing
>>>>>>>>>>>>>>>>> here? Are
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that
>>>>>>>>>>>>>>>>> the JMM
>>>>>>>>>>>>>>>>> defines?
>>>>>>>>>>>>>>>>>>             From what I understand our ppc port is
>>>>>>>>>>>>>>>>>> also affected.
>>>>>>>>>>>>>>>>>> David?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list -
>>>>>>>>>>>>>>>>> sorry.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be
>>>>>>>>>>>>>>>>>> inside  else {}.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64
>>>>>>>>>>>>>>>>>> specific which
>>>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not
>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>> PPC64_ONLY()
>>>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many
>>>>>>>>>>>>>>>>>> #ifdefs.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                if (is_vol) {
>>>>>>>>>>>>>>>>>>                  // See comment in do_get_xxx().
>>>>>>>>>>>>>>>>>> #ifndef PPC64
>>>>>>>>>>>>>>>>>>                  insert_mem_bar(Op_MemBarVolatile); //
>>>>>>>>>>>>>>>>>> Use fat membar
>>>>>>>>>>>>>>>>>> #else
>>>>>>>>>>>>>>>>>>                  if (is_field) {
>>>>>>>>>>>>>>>>>>                    // Add MemBarRelease for
>>>>>>>>>>>>>>>>>> constructors which write
>>>>>>>>>>>>>>>>>> volatile field
>>>>>>>>>>>>>>>>>> (PPC64).
>>>>>>>>>>>>>>>>>>                    set_wrote_volatile(true);
>>>>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the
>>>>>>>>>>>>>>>>>>> VolatileIRIWTest of
>>>>>>>>>>>>>>>>>>> the torture test suite:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Example:
>>>>>>>>>>>>>>>>>>> volatile x=0, y=0
>>>>>>>>>>>>>>>>>>>               __________    __________
>>>>>>>>>>>>>>>>>>> __________    __________
>>>>>>>>>>>>>>>>>>> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                write(x=1)    read(x)
>>>>>>>>>>>>>>>>>>> write(y=1)    read(y)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> read(y)                     read(x)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Disallowed:     x=1, y=0                    y=1, x=0
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Solution: This example requires
>>>>>>>>>>>>>>>>>>> multiple-copy-atomicity. This
>>>>>>>>>>>>>>>>>>> is only
>>>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed
>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as
>>>>>>>>>>>>>>>>>>> sync-load-acquire
>>>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile
>>>>>>>>>>>>>>>>>>> store.
>>>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync.
>>>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple
>>>>>>>>>>>>>>>>>>> SIGSEGVs
>>>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that
>>>>>>>>>>>>>>>>>>> volatile
>>>>>>>>>>>>>>>>>>> fields
>>>>>>>>>>>>>>>>>>> written in constructors are visible before the
>>>>>>>>>>>>>>>>>>> reference gets
>>>>>>>>>>>>>>>>>>> published.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to
>>>>>>>>>>>>>>>>>>> us,
>>>>>>>>>>>>>>>>>>> seems too
>>>>>>>>>>>>>>>>>>> strong.
>>>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore
>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>> suffice.
>>>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please review and test this change.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>               Goetz.
>>>>>>>>>>>>>>>>>>>

From goetz.lindenmaier at sap.com  Fri Jan 24 01:42:03 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 24 Jan 2014 09:42:03 +0000
Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations
	on _thread_state.
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>

Hi,

please review and test this small change:
http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/
Please also review it for jdk8u.

There are concerns that the OrderAccess operations we added to accesses of
_thead_state for ppc64 harm performance on other platforms.  Thus this change adds
guards #ifdef PPC64 around it.

Best regards,
  Goetz.

From david.holmes at oracle.com  Fri Jan 24 03:32:40 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jan 2014 21:32:40 +1000
Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations
	on _thread_state.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E24F58.1090101@oracle.com>

Ok. Thanks Goetz.

David

On 24/01/2014 7:42 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review and test this small change:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/
>
> Please also review it for jdk8u.
>
> There are concerns that the OrderAccess operations we added to accesses of
>
> _/thead/_state for ppc64 harm performance on other platforms.  Thus this
> change adds
>
> guards #ifdef PPC64 around it.
>
> Best regards,
>
>    Goetz.
>

From jesper.wilhelmsson at oracle.com  Fri Jan 24 04:14:45 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 24 Jan 2014 13:14:45 +0100
Subject: RFR (backport): 8032586 Fix typos in the GC code (and runtime and
	compiler as it turned out)
Message-ID: <52E25935.9000001@oracle.com>

Hi,

The typos patch from jdk9/hs-gc applied cleanly on jdk8u/hs-dev so kindly 
approve this for backport to jdk8.

The bugs:
jdk9: https://bugs.openjdk.java.net/browse/JDK-8032586
jdk8: https://bugs.openjdk.java.net/browse/JDK-8025856

Reviews in these threads:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-January/009080.html
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012154.html

The jdk9 changeset:
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/63a4eb8bcd23

Thanks,
/Jesper

From vladimir.kozlov at oracle.com  Fri Jan 24 06:35:56 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 24 Jan 2014 06:35:56 -0800
Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations
	on _thread_state.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E27A4C.6040806@oracle.com>

Why you used #if !defined() instead of #ifndef? We usually use #ifndef when checking one parameter.

Thanks,
Vladimir

On 1/24/14 1:42 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review and test this small change:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/
>
> Please also review it for jdk8u.
>
> There are concerns that the OrderAccess operations we added to accesses of
>
> _/thead/_state for ppc64 harm performance on other platforms.  Thus this change adds
>
> guards #ifdef PPC64 around it.
>
> Best regards,
>
>    Goetz.
>

From vladimir.kozlov at oracle.com  Fri Jan 24 06:46:38 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 24 Jan 2014 06:46:38 -0800
Subject: RFR (backport): 8032586 Fix typos in the GC code (and runtime
	and compiler as it turned out)
In-Reply-To: <52E25935.9000001@oracle.com>
References: <52E25935.9000001@oracle.com>
Message-ID: <52E27CCE.4030800@oracle.com>

I would advise to wait until we release jdk8 and merge its latest changes into 8u.

Thanks,
Vladimir

On 1/24/14 4:14 AM, Jesper Wilhelmsson wrote:
> Hi,
>
> The typos patch from jdk9/hs-gc applied cleanly on jdk8u/hs-dev so kindly approve this for backport to jdk8.
>
> The bugs:
> jdk9: https://bugs.openjdk.java.net/browse/JDK-8032586
> jdk8: https://bugs.openjdk.java.net/browse/JDK-8025856
>
> Reviews in these threads:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-January/009080.html
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012154.html
>
> The jdk9 changeset:
> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/63a4eb8bcd23
>
> Thanks,
> /Jesper

From goetz.lindenmaier at sap.com  Fri Jan 24 06:54:24 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 24 Jan 2014 14:54:24 +0000
Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess
	operations on _thread_state.
In-Reply-To: <52E27A4C.6040806@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
	<52E27A4C.6040806@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8FC6E@DEWDFEMB12A.global.corp.sap>

Hi Vladimir, 

I updated it.

Best regards,
  Goetz.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Freitag, 24. Januar 2014 15:36
To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; David Holmes
Subject: Re: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state.

Why you used #if !defined() instead of #ifndef? We usually use #ifndef when checking one parameter.

Thanks,
Vladimir

On 1/24/14 1:42 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review and test this small change:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/
>
> Please also review it for jdk8u.
>
> There are concerns that the OrderAccess operations we added to accesses of
>
> _/thead/_state for ppc64 harm performance on other platforms.  Thus this change adds
>
> guards #ifdef PPC64 around it.
>
> Best regards,
>
>    Goetz.
>

From vladimir.kozlov at oracle.com  Fri Jan 24 06:56:33 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 24 Jan 2014 06:56:33 -0800
Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations
	on _thread_state.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8FC6E@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
	<52E27A4C.6040806@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE8FC6E@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E27F21.403@oracle.com>

Thanks. I will push it using JPRT.

Vladimir

On 1/24/14 6:54 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> I updated it.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Freitag, 24. Januar 2014 15:36
> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; David Holmes
> Subject: Re: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state.
>
> Why you used #if !defined() instead of #ifndef? We usually use #ifndef when checking one parameter.
>
> Thanks,
> Vladimir
>
> On 1/24/14 1:42 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> please review and test this small change:
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/
>>
>> Please also review it for jdk8u.
>>
>> There are concerns that the OrderAccess operations we added to accesses of
>>
>> _/thead/_state for ppc64 harm performance on other platforms.  Thus this change adds
>>
>> guards #ifdef PPC64 around it.
>>
>> Best regards,
>>
>>     Goetz.
>>

From volker.simonis at gmail.com  Fri Jan 24 09:04:27 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jan 2014 18:04:27 +0100
Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't
	understand two-digit HotSpot minor version numbers
Message-ID: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>

Hi,

could you please review the following trivial change:

http://cr.openjdk.java.net/~simonis/webrevs/8032678/

which fixes the JDK test jdk/test/sun/misc/Version/Version.java to
correctly handle two-digit HotSpot minor version numbers. This became
necessary after change "8031552: Update the Hotspot version numbers in
Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u.

This webrev is for jdk9 but it will have to be backported to jdk8u
because there?s where the current problem happens.

Thanks,
Volker

From vladimir.kozlov at oracle.com  Fri Jan 24 09:13:15 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 24 Jan 2014 09:13:15 -0800
Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't
	understand two-digit HotSpot minor version numbers
In-Reply-To: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>
References: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>
Message-ID: <52E29F2B.4000402@oracle.com>

Good change. I got this failure too.

Thanks,
Vladimir

On 1/24/14 9:04 AM, Volker Simonis wrote:
> Hi,
>
> could you please review the following trivial change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8032678/
>
> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to
> correctly handle two-digit HotSpot minor version numbers. This became
> necessary after change "8031552: Update the Hotspot version numbers in
> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u.
>
> This webrev is for jdk9 but it will have to be backported to jdk8u
> because there?s where the current problem happens.
>
> Thanks,
> Volker
>

From vladimir.kozlov at oracle.com  Fri Jan 24 09:38:52 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 24 Jan 2014 09:38:52 -0800
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E2A52C.3080801@oracle.com>

Hi,

Before the merge of ppc64 port into our main sources I have to undo this 
change which simplified testing (no need for separate JPRT jobs) during 
pushes into ppc64 staging repo.

Gary Collins is working on these changes for our main sources.

http://cr.openjdk.java.net/~kvn/8029941/webrev/

It will also be backported into 8u20 later.

Thanks,
Vladimir


From alejandro.murillo at oracle.com  Fri Jan 24 10:30:01 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 24 Jan 2014 11:30:01 -0700
Subject: Active Hotspot development repos & process summary
Message-ID: <52E2B129.1050003@oracle.com>


There are several active hotspot and JDK development repos and
people seem to be confused about where to  push changes to.
Here's a brief reminder/summary of the process and hotspot repos:

In general hotspot changes are usually pushed to a hotspot specific 
development repo,
in those repos changes go through hotspot specific nightly testing 
during weekdays.
We then take snapshots of those repos in a weekly or so basis, run 
through PIT, usually on weekends,
and then push them to the targeted JDK master repo, except for jdk9,
in which case it is pushed to the jdk9/dev repo.

For hotspot developers, in a nutshell, the general process is:

(1) Mark the bugs appropriately according to the development phase of 
the targeted JDK
- For instance, 7u60 is in RDP2 now, so bugs should be marked 
appropriately and approved
before changes can be pushed to the hotspot repo.

(2) Get peer reviews: usually via email to the appropriate hotspot-dev 
alias.
For backports, if the patch applies cleanly, indicate that in the 
request for review,
so that it can be expedited

(3) Once changes are peer reviewed, push the change to the appropriate 
hotspot repo VIA JPRT

(4) DO NOT NEED to get approval to push to master, as non hotspot 
developers do,
as that will be requested by the gatekeeper before pushing the snapshot 
(bulk integration)
to the master repo.

Note, except for jdk8, all hotspot bugs should be filed against the 
targeted JDK version
the bug is destined for. Hotspot JDK8 bugs should be filed using hs25 as 
the version.

Here's is the summary of the currently active Hotspot development repos
and the target jdk releases:

(1) hs24.60/7u60:
hsx/jdk7u/hotspot

(2) hs25/jdk8:
hsx/hotspot-main/hotspot

(3) hs25.20/jdk8u20:
jdk8u/hs-dev/hotspot

(4) jdk9:
jdk9/hs-[rt,gc,comp,emb]/hotspot

note, all these repos are full JDK forests, so fixes that require 
pushing tightly coupled
hotspot and non hotspot changesets should be pushed through  these repos.
Please give me a heads up if you plan to do so.

JPRT is not available to external developers, so if you do not have JPRT 
access,
please contact me once changes have been peer reviewed and are ready to 
be pushed
to hotspot repo.

Please do not hesitate to contact me if you have any question.
thanks

-- 
Alejandro


From volker.simonis at gmail.com  Fri Jan 24 10:39:14 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jan 2014 19:39:14 +0100
Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't
	understand two-digit HotSpot minor version numbers
In-Reply-To: <52E29F2B.4000402@oracle.com>
References: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>
	<52E29F2B.4000402@oracle.com>
Message-ID: <CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>

Hi Vladimir,

I've just pushed this to jdk9/dev.

I also received an email stating that "this bug needs to be updated,
please request to defer or upgrade to P1 and request for approval". I
assume that's because I entered "8-pool, 9" as "Fix versions".

Now I actually don't know what to do. It seems strange to upgrade this
to P1 because it is only a test bug. On the other hand it is needed in
8u because there's where we have the trouble.

So should I upgrade it to P1 and request approval for jdk8u-dev (or
directly jdk8u)? The actual problem occurs in jdk8u only, because
jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor
number to 20.

Can I push directly to jdk8u or does the change has to go trough jdk8u-dev?

Thanks,
Volker

On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Good change. I got this failure too.
>
> Thanks,
> Vladimir
>
>
> On 1/24/14 9:04 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please review the following trivial change:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/
>>
>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to
>> correctly handle two-digit HotSpot minor version numbers. This became
>> necessary after change "8031552: Update the Hotspot version numbers in
>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u.
>>
>> This webrev is for jdk9 but it will have to be backported to jdk8u
>> because there?s where the current problem happens.
>>
>> Thanks,
>> Volker
>>
>

From joe.darcy at oracle.com  Fri Jan 24 10:47:54 2014
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 24 Jan 2014 10:47:54 -0800
Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't
	understand two-digit HotSpot minor version numbers
In-Reply-To: <CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>
References: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>
	<52E29F2B.4000402@oracle.com>
	<CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>
Message-ID: <52E2B55A.1000807@oracle.com>

I've removed the incorrect-for-JBS multiple release values of "8-pool, 
9" in the fixVersion field of the main bug record.

-Joe

On 1/24/2014 10:39 AM, Volker Simonis wrote:
> Hi Vladimir,
>
> I've just pushed this to jdk9/dev.
>
> I also received an email stating that "this bug needs to be updated,
> please request to defer or upgrade to P1 and request for approval". I
> assume that's because I entered "8-pool, 9" as "Fix versions".
>
> Now I actually don't know what to do. It seems strange to upgrade this
> to P1 because it is only a test bug. On the other hand it is needed in
> 8u because there's where we have the trouble.
>
> So should I upgrade it to P1 and request approval for jdk8u-dev (or
> directly jdk8u)? The actual problem occurs in jdk8u only, because
> jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor
> number to 20.
>
> Can I push directly to jdk8u or does the change has to go trough jdk8u-dev?
>
> Thanks,
> Volker
>
> On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Good change. I got this failure too.
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 1/24/14 9:04 AM, Volker Simonis wrote:
>>> Hi,
>>>
>>> could you please review the following trivial change:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/
>>>
>>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to
>>> correctly handle two-digit HotSpot minor version numbers. This became
>>> necessary after change "8031552: Update the Hotspot version numbers in
>>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u.
>>>
>>> This webrev is for jdk9 but it will have to be backported to jdk8u
>>> because there?s where the current problem happens.
>>>
>>> Thanks,
>>> Volker
>>>


From volker.simonis at gmail.com  Fri Jan 24 10:44:24 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jan 2014 19:44:24 +0100
Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't
	understand two-digit HotSpot minor version numbers
In-Reply-To: <CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>
References: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>
	<52E29F2B.4000402@oracle.com>
	<CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>
Message-ID: <CA+3eh10S8Pj_TS8b2T8e7+WSP+Py5uoHvVRY6dK7AxqE70cFPg@mail.gmail.com>

And I just noticed from Alejandro's mail that there also exists
hs24.60 for 7u60 now. So if somebody is interested in cleanly passing
the jtreg tests on 7u60 this change will also has to be backported to
7u.

On Fri, Jan 24, 2014 at 7:39 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi Vladimir,
>
> I've just pushed this to jdk9/dev.
>
> I also received an email stating that "this bug needs to be updated,
> please request to defer or upgrade to P1 and request for approval". I
> assume that's because I entered "8-pool, 9" as "Fix versions".
>
> Now I actually don't know what to do. It seems strange to upgrade this
> to P1 because it is only a test bug. On the other hand it is needed in
> 8u because there's where we have the trouble.
>
> So should I upgrade it to P1 and request approval for jdk8u-dev (or
> directly jdk8u)? The actual problem occurs in jdk8u only, because
> jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor
> number to 20.
>
> Can I push directly to jdk8u or does the change has to go trough jdk8u-dev?
>
> Thanks,
> Volker
>
> On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Good change. I got this failure too.
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 1/24/14 9:04 AM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> could you please review the following trivial change:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/
>>>
>>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to
>>> correctly handle two-digit HotSpot minor version numbers. This became
>>> necessary after change "8031552: Update the Hotspot version numbers in
>>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u.
>>>
>>> This webrev is for jdk9 but it will have to be backported to jdk8u
>>> because there?s where the current problem happens.
>>>
>>> Thanks,
>>> Volker
>>>
>>

From vladimir.kozlov at oracle.com  Fri Jan 24 10:52:17 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 24 Jan 2014 10:52:17 -0800
Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't
	understand two-digit HotSpot minor version numbers
In-Reply-To: <CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>
References: <CA+3eh10fF=UUmp0SjfjA0t=T6WHDQLw0g1QhgfsFE081=1q3cw@mail.gmail.com>	<52E29F2B.4000402@oracle.com>
	<CA+3eh11+R55tgx6isVT6Q+kpPrQcvMp2bdG1j5ubXc+ELc8nqQ@mail.gmail.com>
Message-ID: <52E2B661.2080300@oracle.com>

I updated Fix versions to 8u20.

No need to upgrade since you are not pushing to jdk8.

You need to send request for approval to push into 8u20 to

jdk8u-dev at openjdk.java.net

I attached example.

After approval, you can push to:

  http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk

Regards,
Vladimir

On 1/24/14 10:39 AM, Volker Simonis wrote:
> Hi Vladimir,
>
> I've just pushed this to jdk9/dev.
>
> I also received an email stating that "this bug needs to be updated,
> please request to defer or upgrade to P1 and request for approval". I
> assume that's because I entered "8-pool, 9" as "Fix versions".
>
> Now I actually don't know what to do. It seems strange to upgrade this
> to P1 because it is only a test bug. On the other hand it is needed in
> 8u because there's where we have the trouble.
>
> So should I upgrade it to P1 and request approval for jdk8u-dev (or
> directly jdk8u)? The actual problem occurs in jdk8u only, because
> jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor
> number to 20.
>
> Can I push directly to jdk8u or does the change has to go trough jdk8u-dev?
>
> Thanks,
> Volker
>
> On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Good change. I got this failure too.
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 1/24/14 9:04 AM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> could you please review the following trivial change:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/
>>>
>>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to
>>> correctly handle two-digit HotSpot minor version numbers. This became
>>> necessary after change "8031552: Update the Hotspot version numbers in
>>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u.
>>>
>>> This webrev is for jdk9 but it will have to be backported to jdk8u
>>> because there?s where the current problem happens.
>>>
>>> Thanks,
>>> Volker
>>>
>>
-------------- next part --------------
An embedded message was scrubbed...
From: Jaroslav Bachorik <jaroslav.bachorik at oracle.com>
Subject: [8u20] request for approval to backport 8022221: Intermittent test
	failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh
Date: Wed, 22 Jan 2014 14:43:23 +0100
Size: 3487
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20140124/3cb4c384/AttachedMessage.nws 

From stefan.reich.maker.of.eye at googlemail.com  Fri Jan 24 12:29:09 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Fri, 24 Jan 2014 21:29:09 +0100
Subject: Combining client and server VM
Message-ID: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>

Hi there!

Is this the official HotSpot list? Looks like it.

I am Stefan. Here's my short bio: I was an early HotSpot adopter (before
its release) and now I reinvent programming (www.TinyBrain.de).

OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
combined into one engine. A combination seems to me like pretty much the
ideal VM to have.

It would basically start as the client VM in order to get stuff started
quickly, least delays possible.

When initialisations are done, after a few seconds or so, the VM switches
to server mode, delivering highly-optimized code.

I need to restart VMs a lot, but I still want maximum performance, for
example for GUIs. It's OK to have a slower GUI for a few seconds if you're
rewarded with full speed shortly after that.

Is it possible? Shouldn't be too hard to implement, right? Anyone up for it?

Cheers,
Stefan

--

Stefan Reich
TinyBrain.de
We will beat Google to A.I.

From schlosna at gmail.com  Fri Jan 24 12:49:10 2014
From: schlosna at gmail.com (David Schlosnagle)
Date: Fri, 24 Jan 2014 15:49:10 -0500
Subject: Combining client and server VM
In-Reply-To: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
Message-ID: <CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>

Sounds like you're describing -XX:+TieredCompilation [1], already available
in HotSpot.

[1]:
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation


On Fri, Jan 24, 2014 at 3:29 PM, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hi there!
>
> Is this the official HotSpot list? Looks like it.
>
> I am Stefan. Here's my short bio: I was an early HotSpot adopter (before
> its release) and now I reinvent programming (www.TinyBrain.de).
>
> OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
> combined into one engine. A combination seems to me like pretty much the
> ideal VM to have.
>
> It would basically start as the client VM in order to get stuff started
> quickly, least delays possible.
>
> When initialisations are done, after a few seconds or so, the VM switches
> to server mode, delivering highly-optimized code.
>
> I need to restart VMs a lot, but I still want maximum performance, for
> example for GUIs. It's OK to have a slower GUI for a few seconds if you're
> rewarded with full speed shortly after that.
>
> Is it possible? Shouldn't be too hard to implement, right? Anyone up for
> it?
>
> Cheers,
> Stefan
>
> --
>
> Stefan Reich
> TinyBrain.de
> We will beat Google to A.I.
>

From azeem.jiva at oracle.com  Fri Jan 24 12:58:14 2014
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Fri, 24 Jan 2014 12:58:14 -0800
Subject: Combining client and server VM
In-Reply-To: <CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
	<CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
Message-ID: <2908728A-221F-4CAB-A19C-9BBB993E45C3@oracle.com>

Also, TieredCompilation is enabled by default in JDK 8.

--
Azeem Jiva
@javawithjiva

On Jan 24, 2014, at 12:49 PM, David Schlosnagle <schlosna at gmail.com> wrote:

> Sounds like you're describing -XX:+TieredCompilation [1], already available
> in HotSpot.
> 
> [1]:
> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation
> 
> 
> On Fri, Jan 24, 2014 at 3:29 PM, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
> 
>> Hi there!
>> 
>> Is this the official HotSpot list? Looks like it.
>> 
>> I am Stefan. Here's my short bio: I was an early HotSpot adopter (before
>> its release) and now I reinvent programming (www.TinyBrain.de).
>> 
>> OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
>> combined into one engine. A combination seems to me like pretty much the
>> ideal VM to have.
>> 
>> It would basically start as the client VM in order to get stuff started
>> quickly, least delays possible.
>> 
>> When initialisations are done, after a few seconds or so, the VM switches
>> to server mode, delivering highly-optimized code.
>> 
>> I need to restart VMs a lot, but I still want maximum performance, for
>> example for GUIs. It's OK to have a slower GUI for a few seconds if you're
>> rewarded with full speed shortly after that.
>> 
>> Is it possible? Shouldn't be too hard to implement, right? Anyone up for
>> it?
>> 
>> Cheers,
>> Stefan
>> 
>> --
>> 
>> Stefan Reich
>> TinyBrain.de
>> We will beat Google to A.I.
>> 


From stefan.reich.maker.of.eye at googlemail.com  Fri Jan 24 14:35:04 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Fri, 24 Jan 2014 23:35:04 +0100
Subject: Combining client and server VM
In-Reply-To: <CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
	<CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
Message-ID: <CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>

Hi David!

Thanks, that was actually new to me even though I'm an avid Java fan.

It does help a bit:

-client

ImageToLua.convert: 170 ms
real    0m4.763s
user    0m1.452s
sys    0m0.124s

-server

ImageToLua.convert: 1108 ms
real    0m12.597s
user    0m7.008s
sys    0m0.388s

-client -XX:+TieredCompilation

ImageToLua.convert: 181 ms
real    0m5.686s
user    0m1.488s
sys    0m0.144s

-server -XX:+TieredCompilation

ImageToLua.convert: 398 ms
real    0m8.827s
user    0m4.572s
sys    0m0.256s

This is a run of a short program (as you can see), so we're testing
start-up time and probably only first-level compilations.
ImageToLua.convert is one of the calculating functions.

So TieredCompilation is indeed faster in startup than the pure server VM.
It still is quite a bit slower than -client, so I'm still lusting for a
perfect solution (start-up performance on part with client VM).

Cheers :)
Stefan



On Fri, Jan 24, 2014 at 9:49 PM, David Schlosnagle <schlosna at gmail.com>wrote:

> Sounds like you're describing -XX:+TieredCompilation [1], already
> available in HotSpot.
>
> [1]:
> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation
>
>
> On Fri, Jan 24, 2014 at 3:29 PM, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
>> Hi there!
>>
>> Is this the official HotSpot list? Looks like it.
>>
>> I am Stefan. Here's my short bio: I was an early HotSpot adopter (before
>> its release) and now I reinvent programming (www.TinyBrain.de).
>>
>> OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
>> combined into one engine. A combination seems to me like pretty much the
>> ideal VM to have.
>>
>> It would basically start as the client VM in order to get stuff started
>> quickly, least delays possible.
>>
>> When initialisations are done, after a few seconds or so, the VM switches
>> to server mode, delivering highly-optimized code.
>>
>> I need to restart VMs a lot, but I still want maximum performance, for
>> example for GUIs. It's OK to have a slower GUI for a few seconds if you're
>> rewarded with full speed shortly after that.
>>
>> Is it possible? Shouldn't be too hard to implement, right? Anyone up for
>> it?
>>
>> Cheers,
>> Stefan
>>
>> --
>>
>> Stefan Reich
>> TinyBrain.de
>> We will beat Google to A.I.
>>
>
>

From aaron.grunthal at infinite-source.de  Fri Jan 24 14:55:29 2014
From: aaron.grunthal at infinite-source.de (Aaron Grunthal)
Date: Fri, 24 Jan 2014 23:55:29 +0100
Subject: Combining client and server VM
In-Reply-To: <CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>	<CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
	<CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>
Message-ID: <52E2EF61.2090109@infinite-source.de>

On 24.01.2014 23:35, Stefan Reich wrote:
> So TieredCompilation is indeed faster in startup than the pure server VM.
> It still is quite a bit slower than -client, so I'm still lusting for a
> perfect solution (start-up performance on part with client VM).

TieredCompilation can be tuned quite a bit:

- you can change the # of compiler threads (CICompilerCount)
- you can tell it it to stop at any tier (1-4) making it more client- or 
server-like
- you can tell it how often a method has to be called before the next 
compiler tier kicks in

Have a look at java -XX:+PrintFlagsFinal | grep Tier

But those parameters have to be tuned for a specific application, so it 
only makes sense if startup time actually is a big bottleneck for you.

Using nailgun or drip are also alternatives to get better startup times.


- Aaron

From rednaxelafx at gmail.com  Fri Jan 24 15:00:16 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Fri, 24 Jan 2014 15:00:16 -0800
Subject: Combining client and server VM
In-Reply-To: <CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
	<CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
	<CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>
Message-ID: <CA+cQ+tTvVhHYGqwo7QCghDMCsjtjm4tf_0qT28OBw6+3QCA+MA@mail.gmail.com>

Hi Stefan,

On what version of JDK are you testing with? Oracle JDK/OpenJDK doesn't
ship a 64-bit Client VM.

Tiered-compilation is only available in the Server VM (which is actually a
Tiered VM now). The Server VM has both the Client Compiler (C1) and Server
Compiler (C2), and in tiered-mode both compilers are active; where as the
Client VM only has C1.

So, turning on -XX:+TieredCompilation with -client doesn't really make
sense.

- Kris


On Fri, Jan 24, 2014 at 2:35 PM, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hi David!
>
> Thanks, that was actually new to me even though I'm an avid Java fan.
>
> It does help a bit:
>
> -client
>
> ImageToLua.convert: 170 ms
> real    0m4.763s
> user    0m1.452s
> sys    0m0.124s
>
> -server
>
> ImageToLua.convert: 1108 ms
> real    0m12.597s
> user    0m7.008s
> sys    0m0.388s
>
> -client -XX:+TieredCompilation
>
> ImageToLua.convert: 181 ms
> real    0m5.686s
> user    0m1.488s
> sys    0m0.144s
>
> -server -XX:+TieredCompilation
>
> ImageToLua.convert: 398 ms
> real    0m8.827s
> user    0m4.572s
> sys    0m0.256s
>
> This is a run of a short program (as you can see), so we're testing
> start-up time and probably only first-level compilations.
> ImageToLua.convert is one of the calculating functions.
>
> So TieredCompilation is indeed faster in startup than the pure server VM.
> It still is quite a bit slower than -client, so I'm still lusting for a
> perfect solution (start-up performance on part with client VM).
>
> Cheers :)
> Stefan
>
>
>
> On Fri, Jan 24, 2014 at 9:49 PM, David Schlosnagle <schlosna at gmail.com
> >wrote:
>
> > Sounds like you're describing -XX:+TieredCompilation [1], already
> > available in HotSpot.
> >
> > [1]:
> >
> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation
> >
> >
> > On Fri, Jan 24, 2014 at 3:29 PM, Stefan Reich <
> > stefan.reich.maker.of.eye at googlemail.com> wrote:
> >
> >> Hi there!
> >>
> >> Is this the official HotSpot list? Looks like it.
> >>
> >> I am Stefan. Here's my short bio: I was an early HotSpot adopter (before
> >> its release) and now I reinvent programming (www.TinyBrain.de).
> >>
> >> OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
> >> combined into one engine. A combination seems to me like pretty much the
> >> ideal VM to have.
> >>
> >> It would basically start as the client VM in order to get stuff started
> >> quickly, least delays possible.
> >>
> >> When initialisations are done, after a few seconds or so, the VM
> switches
> >> to server mode, delivering highly-optimized code.
> >>
> >> I need to restart VMs a lot, but I still want maximum performance, for
> >> example for GUIs. It's OK to have a slower GUI for a few seconds if
> you're
> >> rewarded with full speed shortly after that.
> >>
> >> Is it possible? Shouldn't be too hard to implement, right? Anyone up for
> >> it?
> >>
> >> Cheers,
> >> Stefan
> >>
> >> --
> >>
> >> Stefan Reich
> >> TinyBrain.de
> >> We will beat Google to A.I.
> >>
> >
> >
>

From stefan.reich.maker.of.eye at googlemail.com  Fri Jan 24 15:36:55 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 25 Jan 2014 00:36:55 +0100
Subject: Combining client and server VM
In-Reply-To: <CA+cQ+tTvVhHYGqwo7QCghDMCsjtjm4tf_0qT28OBw6+3QCA+MA@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
	<CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
	<CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>
	<CA+cQ+tTvVhHYGqwo7QCghDMCsjtjm4tf_0qT28OBw6+3QCA+MA@mail.gmail.com>
Message-ID: <CAC2-jLGQXaWs3+dji1Aqs3A9tND8spoC8Ftf=DmmJ1QUUfO3bQ@mail.gmail.com>

Java version:

java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.4)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)

It's all 32 bit.

> So, turning on -XX:+TieredCompilation with -client doesn't really make
sense.

Yup, I figured as much. Included that only to see what the switch does in
both modes.

Stefan



On Sat, Jan 25, 2014 at 12:00 AM, Krystal Mok <rednaxelafx at gmail.com> wrote:

> Hi Stefan,
>
> On what version of JDK are you testing with? Oracle JDK/OpenJDK doesn't
> ship a 64-bit Client VM.
>
> Tiered-compilation is only available in the Server VM (which is actually a
> Tiered VM now). The Server VM has both the Client Compiler (C1) and Server
> Compiler (C2), and in tiered-mode both compilers are active; where as the
> Client VM only has C1.
>
> So, turning on -XX:+TieredCompilation with -client doesn't really make
> sense.
>
> - Kris
>
>
> On Fri, Jan 24, 2014 at 2:35 PM, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
>> Hi David!
>>
>> Thanks, that was actually new to me even though I'm an avid Java fan.
>>
>> It does help a bit:
>>
>> -client
>>
>> ImageToLua.convert: 170 ms
>> real    0m4.763s
>> user    0m1.452s
>> sys    0m0.124s
>>
>> -server
>>
>> ImageToLua.convert: 1108 ms
>> real    0m12.597s
>> user    0m7.008s
>> sys    0m0.388s
>>
>> -client -XX:+TieredCompilation
>>
>> ImageToLua.convert: 181 ms
>> real    0m5.686s
>> user    0m1.488s
>> sys    0m0.144s
>>
>> -server -XX:+TieredCompilation
>>
>> ImageToLua.convert: 398 ms
>> real    0m8.827s
>> user    0m4.572s
>> sys    0m0.256s
>>
>> This is a run of a short program (as you can see), so we're testing
>> start-up time and probably only first-level compilations.
>> ImageToLua.convert is one of the calculating functions.
>>
>> So TieredCompilation is indeed faster in startup than the pure server VM.
>> It still is quite a bit slower than -client, so I'm still lusting for a
>> perfect solution (start-up performance on part with client VM).
>>
>> Cheers :)
>> Stefan
>>
>>
>>
>> On Fri, Jan 24, 2014 at 9:49 PM, David Schlosnagle <schlosna at gmail.com
>> >wrote:
>>
>> > Sounds like you're describing -XX:+TieredCompilation [1], already
>> > available in HotSpot.
>> >
>> > [1]:
>> >
>> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation
>> >
>> >
>> > On Fri, Jan 24, 2014 at 3:29 PM, Stefan Reich <
>> > stefan.reich.maker.of.eye at googlemail.com> wrote:
>> >
>> >> Hi there!
>> >>
>> >> Is this the official HotSpot list? Looks like it.
>> >>
>> >> I am Stefan. Here's my short bio: I was an early HotSpot adopter
>> (before
>> >> its release) and now I reinvent programming (www.TinyBrain.de).
>> >>
>> >> OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
>> >> combined into one engine. A combination seems to me like pretty much
>> the
>> >> ideal VM to have.
>> >>
>> >> It would basically start as the client VM in order to get stuff started
>> >> quickly, least delays possible.
>> >>
>> >> When initialisations are done, after a few seconds or so, the VM
>> switches
>> >> to server mode, delivering highly-optimized code.
>> >>
>> >> I need to restart VMs a lot, but I still want maximum performance, for
>> >> example for GUIs. It's OK to have a slower GUI for a few seconds if
>> you're
>> >> rewarded with full speed shortly after that.
>> >>
>> >> Is it possible? Shouldn't be too hard to implement, right? Anyone up
>> for
>> >> it?
>> >>
>> >> Cheers,
>> >> Stefan
>> >>
>> >> --
>> >>
>> >> Stefan Reich
>> >> TinyBrain.de
>> >> We will beat Google to A.I.
>> >>
>> >
>> >
>>
>
>

From stefan.reich.maker.of.eye at googlemail.com  Fri Jan 24 15:50:26 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 25 Jan 2014 00:50:26 +0100
Subject: Combining client and server VM
In-Reply-To: <CAC2-jLGQXaWs3+dji1Aqs3A9tND8spoC8Ftf=DmmJ1QUUfO3bQ@mail.gmail.com>
References: <CAC2-jLFsBmoiDRAjB2iq7giTZ9_ibLC-QOb_QFZkVrtLGxeOug@mail.gmail.com>
	<CAGVnyzSfvFNq5oEY-YONF=VpPA-q5Wzah8ESjuhM8LKYFJ3FyA@mail.gmail.com>
	<CAC2-jLEsXWE5mbXQvDV_=R4V7EcmmcQpBGF40hif+231Qs+FtA@mail.gmail.com>
	<CA+cQ+tTvVhHYGqwo7QCghDMCsjtjm4tf_0qT28OBw6+3QCA+MA@mail.gmail.com>
	<CAC2-jLGQXaWs3+dji1Aqs3A9tND8spoC8Ftf=DmmJ1QUUfO3bQ@mail.gmail.com>
Message-ID: <CAC2-jLGfWmdPkiNo-xsZpAL2PANR-6qagEDN3UMVyYWYkCBHmA@mail.gmail.com>

Well... I should have used Java 7 in the first place of course. ^^ Times on
OpenJDK 7 improve some more:

-server -XX:+TieredCompilation

ImageToLua.convert: 221 ms
real    0m7.611s
user    0m3.088s
sys    0m0.208s

Closer to the client VM! (Now takes ~twice as long.)

Cheers,
Stefan



On Sat, Jan 25, 2014 at 12:36 AM, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Java version:
>
> java version "1.6.0_27"
> OpenJDK Runtime Environment (IcedTea6 1.12.6)
> (6b27-1.12.6-1ubuntu0.12.04.4)
> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
>
> It's all 32 bit.
>
> > So, turning on -XX:+TieredCompilation with -client doesn't really make
> sense.
>
> Yup, I figured as much. Included that only to see what the switch does in
> both modes.
>
> Stefan
>
>
>
> On Sat, Jan 25, 2014 at 12:00 AM, Krystal Mok <rednaxelafx at gmail.com>wrote:
>
>> Hi Stefan,
>>
>> On what version of JDK are you testing with? Oracle JDK/OpenJDK doesn't
>> ship a 64-bit Client VM.
>>
>> Tiered-compilation is only available in the Server VM (which is actually
>> a Tiered VM now). The Server VM has both the Client Compiler (C1) and
>> Server Compiler (C2), and in tiered-mode both compilers are active; where
>> as the Client VM only has C1.
>>
>> So, turning on -XX:+TieredCompilation with -client doesn't really make
>> sense.
>>
>> - Kris
>>
>>
>> On Fri, Jan 24, 2014 at 2:35 PM, Stefan Reich <
>> stefan.reich.maker.of.eye at googlemail.com> wrote:
>>
>>> Hi David!
>>>
>>> Thanks, that was actually new to me even though I'm an avid Java fan.
>>>
>>> It does help a bit:
>>>
>>> -client
>>>
>>> ImageToLua.convert: 170 ms
>>> real    0m4.763s
>>> user    0m1.452s
>>> sys    0m0.124s
>>>
>>> -server
>>>
>>> ImageToLua.convert: 1108 ms
>>> real    0m12.597s
>>> user    0m7.008s
>>> sys    0m0.388s
>>>
>>> -client -XX:+TieredCompilation
>>>
>>> ImageToLua.convert: 181 ms
>>> real    0m5.686s
>>> user    0m1.488s
>>> sys    0m0.144s
>>>
>>> -server -XX:+TieredCompilation
>>>
>>> ImageToLua.convert: 398 ms
>>> real    0m8.827s
>>> user    0m4.572s
>>> sys    0m0.256s
>>>
>>> This is a run of a short program (as you can see), so we're testing
>>> start-up time and probably only first-level compilations.
>>> ImageToLua.convert is one of the calculating functions.
>>>
>>> So TieredCompilation is indeed faster in startup than the pure server VM.
>>> It still is quite a bit slower than -client, so I'm still lusting for a
>>> perfect solution (start-up performance on part with client VM).
>>>
>>> Cheers :)
>>> Stefan
>>>
>>>
>>>
>>> On Fri, Jan 24, 2014 at 9:49 PM, David Schlosnagle <schlosna at gmail.com
>>> >wrote:
>>>
>>> > Sounds like you're describing -XX:+TieredCompilation [1], already
>>> > available in HotSpot.
>>> >
>>> > [1]:
>>> >
>>> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation
>>> >
>>> >
>>> > On Fri, Jan 24, 2014 at 3:29 PM, Stefan Reich <
>>> > stefan.reich.maker.of.eye at googlemail.com> wrote:
>>> >
>>> >> Hi there!
>>> >>
>>> >> Is this the official HotSpot list? Looks like it.
>>> >>
>>> >> I am Stefan. Here's my short bio: I was an early HotSpot adopter
>>> (before
>>> >> its release) and now I reinvent programming (www.TinyBrain.de).
>>> >>
>>> >> OK, on to the topic: I'd LOVE to see the HotSpot client and server VMs
>>> >> combined into one engine. A combination seems to me like pretty much
>>> the
>>> >> ideal VM to have.
>>> >>
>>> >> It would basically start as the client VM in order to get stuff
>>> started
>>> >> quickly, least delays possible.
>>> >>
>>> >> When initialisations are done, after a few seconds or so, the VM
>>> switches
>>> >> to server mode, delivering highly-optimized code.
>>> >>
>>> >> I need to restart VMs a lot, but I still want maximum performance, for
>>> >> example for GUIs. It's OK to have a slower GUI for a few seconds if
>>> you're
>>> >> rewarded with full speed shortly after that.
>>> >>
>>> >> Is it possible? Shouldn't be too hard to implement, right? Anyone up
>>> for
>>> >> it?
>>> >>
>>> >> Cheers,
>>> >> Stefan
>>> >>
>>> >> --
>>> >>
>>> >> Stefan Reich
>>> >> TinyBrain.de
>>> >> We will beat Google to A.I.
>>> >>
>>> >
>>> >
>>>
>>
>>
>

From stefan.reich.maker.of.eye at googlemail.com  Sat Jan 25 08:24:17 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 25 Jan 2014 17:24:17 +0100
Subject: Combining client and server VM - open request
Message-ID: <CAC2-jLEM64avn3w=iRWKDxdtJY2EaX+GNdQZex6vStHRry2DHg@mail.gmail.com>

Hi again,

I'd like to turn this into an official request. I'm looking for someone
with knowledge on who to handle this kind of stuff to come up with a
combined super HotSpot VM:

-starts as fast as -client
-after some time, optimizes as much as -server

It doesn't exist yet (TieredCompilation is not enough). But it should. And
I believe it must be possible with a little tweaking of HotSpot internals.

:-)

Cheers,
Stefan

From belliottsmith at datastax.com  Sat Jan 25 22:04:44 2014
From: belliottsmith at datastax.com (Benedict Elliott Smith)
Date: Sat, 25 Jan 2014 22:04:44 -0800
Subject: Escape Analysis and Stack Allocation
Message-ID: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>

Hi,

I was digging into some (to me) unexpected behaviour of escape analysis,
namely that some references that clearly weren't escaping, and easily
determined to be so, were not being stack allocated.

So, after some digging through the hotspot code, I discovered some things
that were probably obvious to everyone on this list, but also some things
I'm still a little perplexed about. I was hoping somebody could enlighten
me about the latter.

1) I cannot see a reason why stores to a primitive array, for instance,
should cause the argument to escape in bcEscapeAnalyser.cpp
*iterate_one_block()*; most interestingly, a store to an object array does
not result in this, which seems incongruous;

2) An object array store *does* however result in *set_global_escape()* for
the value being stored, which makes sense, except that this should only be
*set_method_escape()*, as per the paper, in the case where the target array
is one of the method arguments. This seems to be missing, here and for
*putfield*.

Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc. The
fact that these all result in *set_method_escape()*, and that *putfield*and
*aastore* don't optimise *set_global_escape()* to
*set_method_escape()*where possible, seem to point to the conclusion
that *_is_arg_stack
/ set_method_escape()* actually encode only *!is_scalar_replaceable*. Is
this the case? If so, why the confusing name?*


Which leads to a much trickier but more interesting question, which is:
what are the barriers to performing actual stack allocation of full
objects, instead of scalar replacement? It is something I would be keen to
investigate, but given my lack of familiarity with the codebase, it would
be immensely helpful to hear what the major difficulties / showstoppers
might be before trying to attack it.

Thanks in advance,

Benedict


*I do note that in escape.cpp *ArgEscape* is defined and is explicitly
overloaded to include some of the characteristics of *is_scalar_replaceable*.
However the *is_arg_stack()* method is commented with "The given argument
escapes the callee, but does not become globally reachable." which seems to
correspond to *ArgEscape* in the paper, but only *invoke()* seems to follow
the spec, when invoking a method that cannot be analysed, and this would
also be true for *!is_scalar_replaceable.*

From jesper.wilhelmsson at oracle.com  Sun Jan 26 10:57:23 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Sun, 26 Jan 2014 19:57:23 +0100
Subject: RFR (backport): 8032586 Fix typos in the GC code (and runtime and
	compiler as it turned out)
In-Reply-To: <52E27CCE.4030800@oracle.com>
References: <52E25935.9000001@oracle.com> <52E27CCE.4030800@oracle.com>
Message-ID: <1B3F5503-DED7-46BC-B19D-DED73C6A45EF@oracle.com>

Vladimir,

Good point. I'll hold this backport for a while. In the meantime it would be nice to get the required reviews so that I don't have to send another request when it's time to push. :-)
/Jesper

> 24 jan 2014 kl. 15:46 skrev Vladimir Kozlov <vladimir.kozlov at oracle.com>:
> 
> I would advise to wait until we release jdk8 and merge its latest changes into 8u.
> 
> Thanks,
> Vladimir
> 
>> On 1/24/14 4:14 AM, Jesper Wilhelmsson wrote:
>> Hi,
>> 
>> The typos patch from jdk9/hs-gc applied cleanly on jdk8u/hs-dev so kindly approve this for backport to jdk8.
>> 
>> The bugs:
>> jdk9: https://bugs.openjdk.java.net/browse/JDK-8032586
>> jdk8: https://bugs.openjdk.java.net/browse/JDK-8025856
>> 
>> Reviews in these threads:
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-January/009080.html
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012154.html
>> 
>> The jdk9 changeset:
>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/63a4eb8bcd23
>> 
>> Thanks,
>> /Jesper

From aaron.grunthal at infinite-source.de  Sun Jan 26 12:26:19 2014
From: aaron.grunthal at infinite-source.de (Aaron Grunthal)
Date: Sun, 26 Jan 2014 21:26:19 +0100
Subject: Escape Analysis and Stack Allocation
In-Reply-To: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>
References: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>
Message-ID: <52E56F6B.4060202@infinite-source.de>

There also is an issue with merge points [1] which prevents objects in 
loops with an accumulator (e.g. reduce operations on streams) to 
stack-allocate the intermediate values.

[1] https://bugs.openjdk.java.net/browse/JDK-6853701

- Aaron

On 26.01.2014 07:04, Benedict Elliott Smith wrote:
> Hi,
>
> I was digging into some (to me) unexpected behaviour of escape analysis,
> namely that some references that clearly weren't escaping, and easily
> determined to be so, were not being stack allocated.
>
> So, after some digging through the hotspot code, I discovered some things
> that were probably obvious to everyone on this list, but also some things
> I'm still a little perplexed about. I was hoping somebody could enlighten
> me about the latter.
>
> 1) I cannot see a reason why stores to a primitive array, for instance,
> should cause the argument to escape in bcEscapeAnalyser.cpp
> *iterate_one_block()*; most interestingly, a store to an object array does
> not result in this, which seems incongruous;
>
> 2) An object array store *does* however result in *set_global_escape()* for
> the value being stored, which makes sense, except that this should only be
> *set_method_escape()*, as per the paper, in the case where the target array
> is one of the method arguments. This seems to be missing, here and for
> *putfield*.
>
> Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc. The
> fact that these all result in *set_method_escape()*, and that *putfield*and
> *aastore* don't optimise *set_global_escape()* to
> *set_method_escape()*where possible, seem to point to the conclusion
> that *_is_arg_stack
> / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is
> this the case? If so, why the confusing name?*
>
>
> Which leads to a much trickier but more interesting question, which is:
> what are the barriers to performing actual stack allocation of full
> objects, instead of scalar replacement? It is something I would be keen to
> investigate, but given my lack of familiarity with the codebase, it would
> be immensely helpful to hear what the major difficulties / showstoppers
> might be before trying to attack it.
>
> Thanks in advance,
>
> Benedict
>
>
> *I do note that in escape.cpp *ArgEscape* is defined and is explicitly
> overloaded to include some of the characteristics of *is_scalar_replaceable*.
> However the *is_arg_stack()* method is commented with "The given argument
> escapes the callee, but does not become globally reachable." which seems to
> correspond to *ArgEscape* in the paper, but only *invoke()* seems to follow
> the spec, when invoking a method that cannot be analysed, and this would
> also be true for *!is_scalar_replaceable.*
>


From igor.veresov at oracle.com  Sun Jan 26 17:23:03 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Sun, 26 Jan 2014 17:23:03 -0800
Subject: Combining client and server VM - open request
In-Reply-To: <CAC2-jLEM64avn3w=iRWKDxdtJY2EaX+GNdQZex6vStHRry2DHg@mail.gmail.com>
References: <CAC2-jLEM64avn3w=iRWKDxdtJY2EaX+GNdQZex6vStHRry2DHg@mail.gmail.com>
Message-ID: <B24396CD-2570-4671-8BE7-11EDE57193A3@oracle.com>

As with all problems that essentially reduce to the halting problem, with tiered compilation policy the only practical solution are heuristics, which means we are not going to solve all possible inputs optimally. 

This may give you more ideas about how tiered works: http://cr.openjdk.java.net/~iveresov/tiered/Tiered.pdf

igor

On Jan 25, 2014, at 8:24 AM, Stefan Reich <stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hi again,
> 
> I'd like to turn this into an official request. I'm looking for someone
> with knowledge on who to handle this kind of stuff to come up with a
> combined super HotSpot VM:
> 
> -starts as fast as -client
> -after some time, optimizes as much as -server
> 
> It doesn't exist yet (TieredCompilation is not enough). But it should. And
> I believe it must be possible with a little tweaking of HotSpot internals.
> 
> :-)
> 
> Cheers,
> Stefan


From harold.seigel at oracle.com  Mon Jan 27 06:15:40 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 27 Jan 2014 09:15:40 -0500
Subject: RFR(S) 8028553: The JVM should not throw VerifyError when 'overriding'
	a static final method in a superclass
Message-ID: <52E66A0C.4070309@oracle.com>

Hi,

Please review this straightforward backport of the small fix for bug 
8028553 to JDK-8u. The fix ensures that a final method is not static 
before issuing a VerifyError, if another method appears to override the 
final method.  The fix is the same for both JDK-9 and JDK-8u.

This fix was tested with the test in the bug report, the new test, the 
JCK lang and vm tests, defmeth tests, ute verify and quick tests, and 
the hotspot, java util, and java lang jtreg tests.

Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8028553_8u/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8028553_8u/>
Bug: https://bugs.openjdk.java.net/browse/JDK-8028553

Thanks! Harold

From kmcguigan at twitter.com  Mon Jan 27 06:50:17 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Mon, 27 Jan 2014 09:50:17 -0500
Subject: RFR(S) 8028553: The JVM should not throw VerifyError when
	'overriding' a static final method in a superclass
In-Reply-To: <52E66A0C.4070309@oracle.com>
References: <52E66A0C.4070309@oracle.com>
Message-ID: <CADNkbOERUxMMMPqy92qvtjn-M+VdVsuSWda=pfvTL4Qg3cc3-Q@mail.gmail.com>

Look good.


On Mon, Jan 27, 2014 at 9:15 AM, harold seigel <harold.seigel at oracle.com>wrote:

> Hi,
>
> Please review this straightforward backport of the small fix for bug
> 8028553 to JDK-8u. The fix ensures that a final method is not static before
> issuing a VerifyError, if another method appears to override the final
> method.  The fix is the same for both JDK-9 and JDK-8u.
>
> This fix was tested with the test in the bug report, the new test, the JCK
> lang and vm tests, defmeth tests, ute verify and quick tests, and the
> hotspot, java util, and java lang jtreg tests.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8028553_8u/ <
> http://cr.openjdk.java.net/%7Ehseigel/bug_8028553_8u/>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8028553
>
> Thanks! Harold
>

From harold.seigel at oracle.com  Mon Jan 27 07:37:58 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 27 Jan 2014 10:37:58 -0500
Subject: RFR(S) 8028553: The JVM should not throw VerifyError when
	'overriding' a static final method in a superclass
In-Reply-To: <CADNkbOERUxMMMPqy92qvtjn-M+VdVsuSWda=pfvTL4Qg3cc3-Q@mail.gmail.com>
References: <52E66A0C.4070309@oracle.com>
	<CADNkbOERUxMMMPqy92qvtjn-M+VdVsuSWda=pfvTL4Qg3cc3-Q@mail.gmail.com>
Message-ID: <52E67D56.2000108@oracle.com>

Hi Keith,

Thanks for the review.

Harold

On 1/27/2014 9:50 AM, Keith McGuigan wrote:
> Look good.
>
>
> On Mon, Jan 27, 2014 at 9:15 AM, harold seigel 
> <harold.seigel at oracle.com <mailto:harold.seigel at oracle.com>> wrote:
>
>     Hi,
>
>     Please review this straightforward backport of the small fix for
>     bug 8028553 to JDK-8u. The fix ensures that a final method is not
>     static before issuing a VerifyError, if another method appears to
>     override the final method.  The fix is the same for both JDK-9 and
>     JDK-8u.
>
>     This fix was tested with the test in the bug report, the new test,
>     the JCK lang and vm tests, defmeth tests, ute verify and quick
>     tests, and the hotspot, java util, and java lang jtreg tests.
>
>     Open webrev at:
>     http://cr.openjdk.java.net/~hseigel/bug_8028553_8u/
>     <http://cr.openjdk.java.net/%7Ehseigel/bug_8028553_8u/>
>     <http://cr.openjdk.java.net/%7Ehseigel/bug_8028553_8u/>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8028553
>
>     Thanks! Harold
>
>


From lois.foltan at oracle.com  Mon Jan 27 08:38:32 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 27 Jan 2014 11:38:32 -0500
Subject: RFR(S) 8028553: The JVM should not throw VerifyError when
	'overriding' a static final method in a superclass
In-Reply-To: <52E66A0C.4070309@oracle.com>
References: <52E66A0C.4070309@oracle.com>
Message-ID: <52E68B88.2070200@oracle.com>


Looks good.
Lois

On 1/27/2014 9:15 AM, harold seigel wrote:
> Hi,
>
> Please review this straightforward backport of the small fix for bug 
> 8028553 to JDK-8u. The fix ensures that a final method is not static 
> before issuing a VerifyError, if another method appears to override 
> the final method.  The fix is the same for both JDK-9 and JDK-8u.
>
> This fix was tested with the test in the bug report, the new test, the 
> JCK lang and vm tests, defmeth tests, ute verify and quick tests, and 
> the hotspot, java util, and java lang jtreg tests.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8028553_8u/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8028553_8u/>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8028553
>
> Thanks! Harold


From harold.seigel at oracle.com  Mon Jan 27 10:02:25 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 27 Jan 2014 13:02:25 -0500
Subject: RFR(S) 8028553: The JVM should not throw VerifyError when
	'overriding' a static final method in a superclass
In-Reply-To: <52E68B88.2070200@oracle.com>
References: <52E66A0C.4070309@oracle.com> <52E68B88.2070200@oracle.com>
Message-ID: <52E69F31.6050400@oracle.com>

Thanks!
Harold

On 1/27/2014 11:38 AM, Lois Foltan wrote:
>
> Looks good.
> Lois
>
> On 1/27/2014 9:15 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this straightforward backport of the small fix for bug 
>> 8028553 to JDK-8u. The fix ensures that a final method is not static 
>> before issuing a VerifyError, if another method appears to override 
>> the final method.  The fix is the same for both JDK-9 and JDK-8u.
>>
>> This fix was tested with the test in the bug report, the new test, 
>> the JCK lang and vm tests, defmeth tests, ute verify and quick tests, 
>> and the hotspot, java util, and java lang jtreg tests.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8028553_8u/ 
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8028553_8u/>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028553
>>
>> Thanks! Harold
>


From dmitry.samersoff at oracle.com  Mon Jan 27 10:03:13 2014
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Mon, 27 Jan 2014 18:03:13 +0000
Subject: hg: hsx/jdk7u/hotspot: 8031764: tmtools/jmap/heap_config tests fail
	on Linux-ia32 because it Cant attach to the core file
Message-ID: <20140127180319.240E2627CD@hg.openjdk.java.net>

Changeset: 02529fb8a820
Author:    dsamersoff
Date:      2014-01-27 20:29 +0400
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/02529fb8a820

8031764: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file
Summary: Backport of JDK-8025812. We have to round addresses to page boundary.
Reviewed-by: sla, dholmes

! agent/src/os/linux/ps_core.c


From vladimir.kozlov at oracle.com  Mon Jan 27 11:09:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 27 Jan 2014 11:09:31 -0800
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <52E2A52C.3080801@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
	<52E2A52C.3080801@oracle.com>
Message-ID: <52E6AEEB.50701@oracle.com>

I still need official reviewer for this change.

Thanks,
Vladimir

On 1/24/14 9:38 AM, Vladimir Kozlov wrote:
> Hi,
>
> Before the merge of ppc64 port into our main sources I have to undo this
> change which simplified testing (no need for separate JPRT jobs) during
> pushes into ppc64 staging repo.
>
> Gary Collins is working on these changes for our main sources.
>
> http://cr.openjdk.java.net/~kvn/8029941/webrev/
>
> It will also be backported into 8u20 later.
>
> Thanks,
> Vladimir
>

From vladimir.kozlov at oracle.com  Mon Jan 27 11:34:23 2014
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Mon, 27 Jan 2014 19:34:23 +0000
Subject: hg: hsx/hotspot-main/hotspot: 8032566: Crash in JIT when running
	Scala compiler (and compiling Scala std lib)
Message-ID: <20140127193426.4EFE2627CF@hg.openjdk.java.net>

Changeset: 2185d483f5f8
Author:    kvn
Date:      2014-01-27 10:20 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2185d483f5f8

8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib)
Summary: Switch off EliminateAutoBox flag by default in jdk8 release.
Reviewed-by: iveresov

! src/share/vm/opto/c2_globals.hpp


From zhengyu.gu at oracle.com  Mon Jan 27 12:17:57 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 27 Jan 2014 15:17:57 -0500
Subject: RFR(XS) 8032827: NMT: missing virtual memory tagging in
	os::workaround_expand_exec_shield_cs_limit()
Message-ID: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>

This is a simple fix for missing NMT tagging on virtual memory reserved in os::workaround_expand_exec_shield_cs_limit() function (Linux 32 only)

Bug: https://bugs.openjdk.java.net/browse/JDK-8032827
Webrev: http://cr.openjdk.java.net/~zgu/8032827/webrev.00/


Thanks,

-Zhengyu


From harold.seigel at oracle.com  Mon Jan 27 13:33:37 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 27 Jan 2014 16:33:37 -0500
Subject: RFR(XS) 8032827: NMT: missing virtual memory tagging in
	os::workaround_expand_exec_shield_cs_limit()
In-Reply-To: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>
References: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>
Message-ID: <52E6D0B1.9060301@oracle.com>

Hi Zhengyu,

The change looks good.

Harold
On 1/27/2014 3:17 PM, Zhengyu Gu wrote:
> This is a simple fix for missing NMT tagging on virtual memory reserved in os::workaround_expand_exec_shield_cs_limit() function (Linux 32 only)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8032827
> Webrev: http://cr.openjdk.java.net/~zgu/8032827/webrev.00/
>
>
> Thanks,
>
> -Zhengyu
>


From roland.westrelin at oracle.com  Mon Jan 27 13:36:08 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 27 Jan 2014 22:36:08 +0100
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <52E2A52C.3080801@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
	<52E2A52C.3080801@oracle.com>
Message-ID: <2D1479C2-F541-4B27-9630-835F39292989@oracle.com>

> http://cr.openjdk.java.net/~kvn/8029941/webrev/

That looks good to me.

Roland.

From vladimir.kozlov at oracle.com  Mon Jan 27 13:36:56 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 27 Jan 2014 13:36:56 -0800
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <2D1479C2-F541-4B27-9630-835F39292989@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
	<52E2A52C.3080801@oracle.com>
	<2D1479C2-F541-4B27-9630-835F39292989@oracle.com>
Message-ID: <52E6D178.6070508@oracle.com>

Thank you, Roland

Vladimir

On 1/27/14 1:36 PM, Roland Westrelin wrote:
>> http://cr.openjdk.java.net/~kvn/8029941/webrev/
>
> That looks good to me.
>
> Roland.
>

From david.holmes at oracle.com  Mon Jan 27 13:44:32 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Jan 2014 07:44:32 +1000
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <52E2A52C.3080801@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>
	<52E2A52C.3080801@oracle.com>
Message-ID: <52E6D340.3020601@oracle.com>

Vladimir,

On 25/01/2014 3:38 AM, Vladimir Kozlov wrote:
> Hi,
>
> Before the merge of ppc64 port into our main sources I have to undo this
> change which simplified testing (no need for separate JPRT jobs) during
> pushes into ppc64 staging repo.

I don't understand why this change is needed. Please explain the 
connection with PPC64.

Thanks,
David

> Gary Collins is working on these changes for our main sources.
>
> http://cr.openjdk.java.net/~kvn/8029941/webrev/
>
> It will also be backported into 8u20 later.
>
> Thanks,
> Vladimir
>

From david.holmes at oracle.com  Mon Jan 27 14:43:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Jan 2014 08:43:42 +1000
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <52E6D340.3020601@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>	<52E2A52C.3080801@oracle.com>
	<52E6D340.3020601@oracle.com>
Message-ID: <52E6E11E.2090501@oracle.com>

On 28/01/2014 7:44 AM, David Holmes wrote:
> Vladimir,
>
> On 25/01/2014 3:38 AM, Vladimir Kozlov wrote:
>> Hi,
>>
>> Before the merge of ppc64 port into our main sources I have to undo this
>> change which simplified testing (no need for separate JPRT jobs) during
>> pushes into ppc64 staging repo.
>
> I don't understand why this change is needed. Please explain the
> connection with PPC64.

Okay - this was stuff merged by accident and needing cleanup.

Reviewed.

Thanks,
David


> Thanks,
> David
>
>> Gary Collins is working on these changes for our main sources.
>>
>> http://cr.openjdk.java.net/~kvn/8029941/webrev/
>>
>> It will also be backported into 8u20 later.
>>
>> Thanks,
>> Vladimir
>>

From vladimir.kozlov at oracle.com  Mon Jan 27 14:48:00 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 27 Jan 2014 14:48:00 -0800
Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties
	for embedded testing
In-Reply-To: <52E6E11E.2090501@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap>	<52E2A52C.3080801@oracle.com>
	<52E6D340.3020601@oracle.com> <52E6E11E.2090501@oracle.com>
Message-ID: <52E6E220.6080806@oracle.com>

Thank you, David

Vladimir

On 1/27/14 2:43 PM, David Holmes wrote:
> On 28/01/2014 7:44 AM, David Holmes wrote:
>> Vladimir,
>>
>> On 25/01/2014 3:38 AM, Vladimir Kozlov wrote:
>>> Hi,
>>>
>>> Before the merge of ppc64 port into our main sources I have to undo this
>>> change which simplified testing (no need for separate JPRT jobs) during
>>> pushes into ppc64 staging repo.
>>
>> I don't understand why this change is needed. Please explain the
>> connection with PPC64.
>
> Okay - this was stuff merged by accident and needing cleanup.
>
> Reviewed.
>
> Thanks,
> David
>
>
>> Thanks,
>> David
>>
>>> Gary Collins is working on these changes for our main sources.
>>>
>>> http://cr.openjdk.java.net/~kvn/8029941/webrev/
>>>
>>> It will also be backported into 8u20 later.
>>>
>>> Thanks,
>>> Vladimir
>>>

From coleen.phillimore at oracle.com  Mon Jan 27 15:14:26 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 27 Jan 2014 18:14:26 -0500
Subject: RFR(XS) 8032827: NMT: missing virtual memory tagging in
	os::workaround_expand_exec_shield_cs_limit()
In-Reply-To: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>
References: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>
Message-ID: <52E6E852.4090302@oracle.com>

Looks good.
Coleen

On 1/27/14 3:17 PM, Zhengyu Gu wrote:
> This is a simple fix for missing NMT tagging on virtual memory reserved in os::workaround_expand_exec_shield_cs_limit() function (Linux 32 only)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8032827
> Webrev: http://cr.openjdk.java.net/~zgu/8032827/webrev.00/
>
>
> Thanks,
>
> -Zhengyu
>


From jeremymanson at google.com  Mon Jan 27 21:21:33 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 27 Jan 2014 21:21:33 -0800
Subject: Escape Analysis and Stack Allocation
In-Reply-To: <52E56F6B.4060202@infinite-source.de>
References: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>
	<52E56F6B.4060202@infinite-source.de>
Message-ID: <CAPYFHW11hXbZ-Epd3x_MJGhASX8HGqRjq+B9O4Pv4L2ynaP5mA@mail.gmail.com>

I tried implementing direct stack allocation in Hotspot a couple of years
ago.  It was a pain to try to allocate anything outside the heap - there
are a lot of checks to make sure that your objects live on the heap.

I ended up creating TLAB-like regions in the heap that could hold objects
allocated in a stack-like way.  It was a lot easier that way, and seemed to
give the kinds of performance benefits you would expect.

I never got around to trying to wire it up to Hotspot's escape analysis,
but it was a fairly obvious next step.

Jeremy


On Sun, Jan 26, 2014 at 12:26 PM, Aaron Grunthal <
aaron.grunthal at infinite-source.de> wrote:

> There also is an issue with merge points [1] which prevents objects in
> loops with an accumulator (e.g. reduce operations on streams) to
> stack-allocate the intermediate values.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6853701
>
> - Aaron
>
>
> On 26.01.2014 07:04, Benedict Elliott Smith wrote:
>
>> Hi,
>>
>> I was digging into some (to me) unexpected behaviour of escape analysis,
>> namely that some references that clearly weren't escaping, and easily
>> determined to be so, were not being stack allocated.
>>
>> So, after some digging through the hotspot code, I discovered some things
>> that were probably obvious to everyone on this list, but also some things
>> I'm still a little perplexed about. I was hoping somebody could enlighten
>> me about the latter.
>>
>> 1) I cannot see a reason why stores to a primitive array, for instance,
>> should cause the argument to escape in bcEscapeAnalyser.cpp
>> *iterate_one_block()*; most interestingly, a store to an object array does
>> not result in this, which seems incongruous;
>>
>> 2) An object array store *does* however result in *set_global_escape()*
>> for
>> the value being stored, which makes sense, except that this should only be
>> *set_method_escape()*, as per the paper, in the case where the target
>> array
>> is one of the method arguments. This seems to be missing, here and for
>> *putfield*.
>>
>> Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc. The
>> fact that these all result in *set_method_escape()*, and that
>> *putfield*and
>> *aastore* don't optimise *set_global_escape()* to
>> *set_method_escape()*where possible, seem to point to the conclusion
>> that *_is_arg_stack
>> / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is
>> this the case? If so, why the confusing name?*
>>
>>
>> Which leads to a much trickier but more interesting question, which is:
>> what are the barriers to performing actual stack allocation of full
>> objects, instead of scalar replacement? It is something I would be keen to
>> investigate, but given my lack of familiarity with the codebase, it would
>> be immensely helpful to hear what the major difficulties / showstoppers
>> might be before trying to attack it.
>>
>> Thanks in advance,
>>
>> Benedict
>>
>>
>> *I do note that in escape.cpp *ArgEscape* is defined and is explicitly
>> overloaded to include some of the characteristics of
>> *is_scalar_replaceable*.
>> However the *is_arg_stack()* method is commented with "The given argument
>> escapes the callee, but does not become globally reachable." which seems
>> to
>> correspond to *ArgEscape* in the paper, but only *invoke()* seems to
>> follow
>> the spec, when invoking a method that cannot be analysed, and this would
>> also be true for *!is_scalar_replaceable.*
>>
>>
>

From david.holmes at oracle.com  Mon Jan 27 22:06:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Jan 2014 16:06:06 +1000
Subject: Default methods: Possible problem with JDWP sendMethod resolution
	semantics
In-Reply-To: <9E355FCC-F91B-442D-B7F5-28E139579AE3@selskabet.org>
References: <9E355FCC-F91B-442D-B7F5-28E139579AE3@selskabet.org>
Message-ID: <52E748CE.9050504@oracle.com>

Hi Jesper,

This seems more of an issue with the hotspot runtime so cc'd hotspot-dev.

David

On 27/01/2014 11:37 PM, Jesper Steen M?ller wrote:
> Hi list
>
> I realize that this is possibly not the right list, but I'm having a lambda-related problem with the JDWP protocol (from the Eclipse Java Debugger)
> The problem is that I cannot invoke the default method of an interface using the equivalent of the superclass invocation syntax. Consider this example:
>
> public interface A {
> 	default int getOne() {
> 		return 1;
> 	}
> }
>
> public interface B {
> 	default int getOne() {
> 		return 2;
> 	}
> }
>
> public class Impl implements A, B {
> 	public int getOne() {
> 		return B.super.getOne() + 3; // stop here and inspect B.super.getOne()
> 	}
> 	public static void main(String[] args) {
> 		Impl i = new Impl();
> 		System.out.println(i.getOne());
> 	}
> }
>
> Now, consider the line with the comment "stop here ...". Assume I have a suspended thread on that line, and I wish to inspect "B.super.getOne()", i.e. invoke the method B.getOne, using the 'this' reference as the receiver. So, I'm sending a "Invoke Method" command under the ObjectReference Command Set, like this:
>
> object	 -  objectID of 'this'
> thread       - threadID of suspended thread
> clazz         - classID of 'B'
> method     - methodID of 'B.getOne'
> arguments - 0
> option      - 3 (this INVOKE_SINGLE_THREADED + INVOKE_NONVIRTUALINVOKE_NONVIRTUAL)
>
> However, the return value is '5' which indicates that the usual virtual call semantics were used on 'this'. Is this supposed to work? Have anyone tried this?
>
> TIA,
> Jesper
>
>

From vladimir.kozlov at oracle.com  Mon Jan 27 22:08:20 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 27 Jan 2014 22:08:20 -0800
Subject: Escape Analysis and Stack Allocation
In-Reply-To: <CAPYFHW11hXbZ-Epd3x_MJGhASX8HGqRjq+B9O4Pv4L2ynaP5mA@mail.gmail.com>
References: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>	<52E56F6B.4060202@infinite-source.de>
	<CAPYFHW11hXbZ-Epd3x_MJGhASX8HGqRjq+B9O4Pv4L2ynaP5mA@mail.gmail.com>
Message-ID: <52E74954.9050608@oracle.com>

I did the same experiment 4 years ago, back in jdk6 era. Called it MLAB, method local allocation buffer, works like 
thread local stack for non-escaping objects but was allocated in java heap as special TLAB. Got it worked but did not 
see benefits in jbb2005. GC requires no holes in heap, as result I had to give the buffer back to GC when young gen 
collection was needed. After GC a thread get new MLAB and starts allocation from scratch which nullified performance 
benefits.

I can try to find those changes if someone interested.

Regards,
Vladimir

On 1/27/14 9:21 PM, Jeremy Manson wrote:
> I tried implementing direct stack allocation in Hotspot a couple of years
> ago.  It was a pain to try to allocate anything outside the heap - there
> are a lot of checks to make sure that your objects live on the heap.
>
> I ended up creating TLAB-like regions in the heap that could hold objects
> allocated in a stack-like way.  It was a lot easier that way, and seemed to
> give the kinds of performance benefits you would expect.
>
> I never got around to trying to wire it up to Hotspot's escape analysis,
> but it was a fairly obvious next step.
>
> Jeremy
>
>
> On Sun, Jan 26, 2014 at 12:26 PM, Aaron Grunthal <
> aaron.grunthal at infinite-source.de> wrote:
>
>> There also is an issue with merge points [1] which prevents objects in
>> loops with an accumulator (e.g. reduce operations on streams) to
>> stack-allocate the intermediate values.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6853701
>>
>> - Aaron
>>
>>
>> On 26.01.2014 07:04, Benedict Elliott Smith wrote:
>>
>>> Hi,
>>>
>>> I was digging into some (to me) unexpected behaviour of escape analysis,
>>> namely that some references that clearly weren't escaping, and easily
>>> determined to be so, were not being stack allocated.
>>>
>>> So, after some digging through the hotspot code, I discovered some things
>>> that were probably obvious to everyone on this list, but also some things
>>> I'm still a little perplexed about. I was hoping somebody could enlighten
>>> me about the latter.
>>>
>>> 1) I cannot see a reason why stores to a primitive array, for instance,
>>> should cause the argument to escape in bcEscapeAnalyser.cpp
>>> *iterate_one_block()*; most interestingly, a store to an object array does
>>> not result in this, which seems incongruous;
>>>
>>> 2) An object array store *does* however result in *set_global_escape()*
>>> for
>>> the value being stored, which makes sense, except that this should only be
>>> *set_method_escape()*, as per the paper, in the case where the target
>>> array
>>> is one of the method arguments. This seems to be missing, here and for
>>> *putfield*.
>>>
>>> Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc. The
>>> fact that these all result in *set_method_escape()*, and that
>>> *putfield*and
>>> *aastore* don't optimise *set_global_escape()* to
>>> *set_method_escape()*where possible, seem to point to the conclusion
>>> that *_is_arg_stack
>>> / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is
>>> this the case? If so, why the confusing name?*
>>>
>>>
>>> Which leads to a much trickier but more interesting question, which is:
>>> what are the barriers to performing actual stack allocation of full
>>> objects, instead of scalar replacement? It is something I would be keen to
>>> investigate, but given my lack of familiarity with the codebase, it would
>>> be immensely helpful to hear what the major difficulties / showstoppers
>>> might be before trying to attack it.
>>>
>>> Thanks in advance,
>>>
>>> Benedict
>>>
>>>
>>> *I do note that in escape.cpp *ArgEscape* is defined and is explicitly
>>> overloaded to include some of the characteristics of
>>> *is_scalar_replaceable*.
>>> However the *is_arg_stack()* method is commented with "The given argument
>>> escapes the callee, but does not become globally reachable." which seems
>>> to
>>> correspond to *ArgEscape* in the paper, but only *invoke()* seems to
>>> follow
>>> the spec, when invoking a method that cannot be analysed, and this would
>>> also be true for *!is_scalar_replaceable.*
>>>
>>>
>>

From jaroslav.bachorik at oracle.com  Mon Jan 27 23:35:19 2014
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 28 Jan 2014 08:35:19 +0100
Subject: Default methods: Possible problem with JDWP sendMethod resolution
	semantics
In-Reply-To: <52E748CE.9050504@oracle.com>
References: <9E355FCC-F91B-442D-B7F5-28E139579AE3@selskabet.org>
	<52E748CE.9050504@oracle.com>
Message-ID: <52E75DB7.6040307@oracle.com>

Hi,

I think this is related to 
https://bugs.openjdk.java.net/browse/JDK-8031195 
(com.sun.jdi.InterfaceType.invokeMethod() is missing)

-JB-

On 28.1.2014 07:06, David Holmes wrote:
> Hi Jesper,
>
> This seems more of an issue with the hotspot runtime so cc'd hotspot-dev.
>
> David
>
> On 27/01/2014 11:37 PM, Jesper Steen M?ller wrote:
>> Hi list
>>
>> I realize that this is possibly not the right list, but I'm having a
>> lambda-related problem with the JDWP protocol (from the Eclipse Java
>> Debugger)
>> The problem is that I cannot invoke the default method of an interface
>> using the equivalent of the superclass invocation syntax. Consider
>> this example:
>>
>> public interface A {
>>     default int getOne() {
>>         return 1;
>>     }
>> }
>>
>> public interface B {
>>     default int getOne() {
>>         return 2;
>>     }
>> }
>>
>> public class Impl implements A, B {
>>     public int getOne() {
>>         return B.super.getOne() + 3; // stop here and inspect
>> B.super.getOne()
>>     }
>>     public static void main(String[] args) {
>>         Impl i = new Impl();
>>         System.out.println(i.getOne());
>>     }
>> }
>>
>> Now, consider the line with the comment "stop here ...". Assume I have
>> a suspended thread on that line, and I wish to inspect
>> "B.super.getOne()", i.e. invoke the method B.getOne, using the 'this'
>> reference as the receiver. So, I'm sending a "Invoke Method" command
>> under the ObjectReference Command Set, like this:
>>
>> object     -  objectID of 'this'
>> thread       - threadID of suspended thread
>> clazz         - classID of 'B'
>> method     - methodID of 'B.getOne'
>> arguments - 0
>> option      - 3 (this INVOKE_SINGLE_THREADED +
>> INVOKE_NONVIRTUALINVOKE_NONVIRTUAL)
>>
>> However, the return value is '5' which indicates that the usual
>> virtual call semantics were used on 'this'. Is this supposed to work?
>> Have anyone tried this?
>>
>> TIA,
>> Jesper
>>
>>


From jeremymanson at google.com  Mon Jan 27 23:44:50 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 27 Jan 2014 23:44:50 -0800
Subject: Escape Analysis and Stack Allocation
In-Reply-To: <52E74954.9050608@oracle.com>
References: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>
	<52E56F6B.4060202@infinite-source.de>
	<CAPYFHW11hXbZ-Epd3x_MJGhASX8HGqRjq+B9O4Pv4L2ynaP5mA@mail.gmail.com>
	<52E74954.9050608@oracle.com>
Message-ID: <CAPYFHW1LMgQCECcXCd2x860DNG9AWZAr+cmyEz-fJxrvyvMspg@mail.gmail.com>

That was basically what mine did, too.  I put on a pointy hat and became
more of a manager than a programmer, but I never stopped wondering what
would happen if I had an opportunity to wire the two things together.

There are obvious optimizations to make, too.  For example, the MLAB
doesn't have to go in the YG - it could go in a generation devoted to them.
 They can be stolen by a second thread when the first thread blocks (TLABs
could do this, too - always wondered why they didn't).  You would probably
want to resize MLABs like you resize TLABs.  It's a career path getting it
right.

If you have something that can go into HS24 pretty easily, I can probably
slap it in and try it out on some programs that are substantially more
interesting than jbb2005.  Might be hard to revive after four years, though.

Jeremy


On Mon, Jan 27, 2014 at 10:08 PM, Vladimir Kozlov <
vladimir.kozlov at oracle.com> wrote:

> I did the same experiment 4 years ago, back in jdk6 era. Called it MLAB,
> method local allocation buffer, works like thread local stack for
> non-escaping objects but was allocated in java heap as special TLAB. Got it
> worked but did not see benefits in jbb2005. GC requires no holes in heap,
> as result I had to give the buffer back to GC when young gen collection was
> needed. After GC a thread get new MLAB and starts allocation from scratch
> which nullified performance benefits.
>
> I can try to find those changes if someone interested.
>
> Regards,
> Vladimir
>
>
> On 1/27/14 9:21 PM, Jeremy Manson wrote:
>
>> I tried implementing direct stack allocation in Hotspot a couple of years
>> ago.  It was a pain to try to allocate anything outside the heap - there
>> are a lot of checks to make sure that your objects live on the heap.
>>
>> I ended up creating TLAB-like regions in the heap that could hold objects
>> allocated in a stack-like way.  It was a lot easier that way, and seemed
>> to
>> give the kinds of performance benefits you would expect.
>>
>> I never got around to trying to wire it up to Hotspot's escape analysis,
>> but it was a fairly obvious next step.
>>
>> Jeremy
>>
>>
>> On Sun, Jan 26, 2014 at 12:26 PM, Aaron Grunthal <
>> aaron.grunthal at infinite-source.de> wrote:
>>
>>  There also is an issue with merge points [1] which prevents objects in
>>> loops with an accumulator (e.g. reduce operations on streams) to
>>> stack-allocate the intermediate values.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-6853701
>>>
>>> - Aaron
>>>
>>>
>>> On 26.01.2014 07:04, Benedict Elliott Smith wrote:
>>>
>>>  Hi,
>>>>
>>>> I was digging into some (to me) unexpected behaviour of escape analysis,
>>>> namely that some references that clearly weren't escaping, and easily
>>>> determined to be so, were not being stack allocated.
>>>>
>>>> So, after some digging through the hotspot code, I discovered some
>>>> things
>>>> that were probably obvious to everyone on this list, but also some
>>>> things
>>>> I'm still a little perplexed about. I was hoping somebody could
>>>> enlighten
>>>> me about the latter.
>>>>
>>>> 1) I cannot see a reason why stores to a primitive array, for instance,
>>>> should cause the argument to escape in bcEscapeAnalyser.cpp
>>>> *iterate_one_block()*; most interestingly, a store to an object array
>>>> does
>>>> not result in this, which seems incongruous;
>>>>
>>>> 2) An object array store *does* however result in *set_global_escape()*
>>>> for
>>>> the value being stored, which makes sense, except that this should only
>>>> be
>>>> *set_method_escape()*, as per the paper, in the case where the target
>>>> array
>>>> is one of the method arguments. This seems to be missing, here and for
>>>> *putfield*.
>>>>
>>>> Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc.
>>>> The
>>>> fact that these all result in *set_method_escape()*, and that
>>>> *putfield*and
>>>> *aastore* don't optimise *set_global_escape()* to
>>>> *set_method_escape()*where possible, seem to point to the conclusion
>>>> that *_is_arg_stack
>>>> / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is
>>>> this the case? If so, why the confusing name?*
>>>>
>>>>
>>>> Which leads to a much trickier but more interesting question, which is:
>>>> what are the barriers to performing actual stack allocation of full
>>>> objects, instead of scalar replacement? It is something I would be keen
>>>> to
>>>> investigate, but given my lack of familiarity with the codebase, it
>>>> would
>>>> be immensely helpful to hear what the major difficulties / showstoppers
>>>> might be before trying to attack it.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Benedict
>>>>
>>>>
>>>> *I do note that in escape.cpp *ArgEscape* is defined and is explicitly
>>>> overloaded to include some of the characteristics of
>>>> *is_scalar_replaceable*.
>>>> However the *is_arg_stack()* method is commented with "The given
>>>> argument
>>>> escapes the callee, but does not become globally reachable." which seems
>>>> to
>>>> correspond to *ArgEscape* in the paper, but only *invoke()* seems to
>>>> follow
>>>> the spec, when invoking a method that cannot be analysed, and this would
>>>> also be true for *!is_scalar_replaceable.*
>>>>
>>>>
>>>>
>>>

From thomas.schatzl at oracle.com  Tue Jan 28 01:41:29 2014
From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com)
Date: Tue, 28 Jan 2014 09:41:29 +0000
Subject: hg: hsx/jdk7u/hotspot: 12 new changesets
Message-ID: <20140128094158.7B7FC627F5@hg.openjdk.java.net>

Changeset: 2b97745f0735
Author:    johnc
Date:      2013-12-19 09:21 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2b97745f0735

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java

Changeset: a4bcd7d65291
Author:    stefank
Date:      2013-12-19 09:21 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a4bcd7d65291

8013132: Add a flag to turn off the output of the verbose verification code
Reviewed-by: johnc, brutisso

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.hpp

Changeset: 1534133741c2
Author:    tschatzl
Date:      2013-12-19 09:21 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1534133741c2

8014240: G1: Add remembered set size information to output of G1PrintRegionLivenessInfo
Summary: Improve the output of G1PrintRegionLivenessInfo by adding a per-region remembered set size information column
Reviewed-by: jwilhelm, johnc

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
+ test/gc/g1/TestPrintRegionRememberedSetInfo.java

Changeset: dc5ea6e27195
Author:    tschatzl
Date:      2013-12-19 09:21 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/dc5ea6e27195

8013895: G1: G1SummarizeRSetStats output on Linux needs improvement
Summary: Fixed the output of G1SummarizeRSetStats: too small datatype for the number of concurrently processed cards, added concurrent remembered set thread time retrieval for Linux and Windows (BSD uses os::elapsedTime() now), and other cleanup. The information presented during VM operation is now relative to the previous output, not always cumulative if G1SummarizeRSetStatsPeriod > 0. At VM exit, the code prints a cumulative summary.
Reviewed-by: johnc, jwilhelm

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
+ src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
+ src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp
+ test/gc/g1/TestSummarizeRSetStats.java

Changeset: 7afe50dc6b9f
Author:    johnc
Date:      2013-12-19 09:21 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/7afe50dc6b9f

8015244: G1: Verification after a full GC is incorrectly placed.
Summary: In a full GC, move the verification after the GC to after RSet rebuilding. Verify RSet entries during a full GC under control of a flag.
Reviewed-by: tschatzl, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: 0114a0a4434c
Author:    johnc
Date:      2014-01-22 13:28 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/0114a0a4434c

7145569: G1: optimize nmethods scanning
Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead.
Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/iterator.cpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/utilities/growableArray.hpp

Changeset: 4923cab3640c
Author:    brutisso
Date:      2013-12-19 09:22 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4923cab3640c

8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0
Reviewed-by: stefank, mgerdin

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 03ecf4784ddd
Author:    tschatzl
Date:      2013-12-19 09:22 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/03ecf4784ddd

8014078: G1: improve remembered set summary information by providing per region type information
Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! test/gc/g1/TestSummarizeRSetStats.java
+ test/gc/g1/TestSummarizeRSetStatsPerRegion.java
+ test/gc/g1/TestSummarizeRSetStatsTools.java

Changeset: f6c3b2632e00
Author:    tschatzl
Date:      2013-12-19 09:22 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f6c3b2632e00

8025541: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads
Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp
+ test/gc/g1/TestSummarizeRSetStatsThreads.java

Changeset: e4bcd3d62466
Author:    sjohanss
Date:      2013-12-19 09:22 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/e4bcd3d62466

8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash
Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values.
Reviewed-by: stefank, ehelin

! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp

Changeset: 05e7f9c0c822
Author:    tschatzl
Date:      2013-12-19 09:22 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/05e7f9c0c822

8027756: assert(!hr->isHumongous()) failed: code root in humongous region?
Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts.
Reviewed-by: jmasa, tamao

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/prims/whitebox.cpp
+ test/gc/g1/TestHumongousCodeCacheRoots.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 81194fd56a9d
Author:    tschatzl
Date:      2013-12-19 09:22 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/81194fd56a9d

8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build"
Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed
Reviewed-by: brutisso, mgerdin

! test/gc/g1/TestPrintRegionRememberedSetInfo.java


From staffan.larsen at oracle.com  Tue Jan 28 02:43:01 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 28 Jan 2014 11:43:01 +0100
Subject: Default methods: Possible problem with JDWP sendMethod resolution
	semantics
In-Reply-To: <52E75DB7.6040307@oracle.com>
References: <9E355FCC-F91B-442D-B7F5-28E139579AE3@selskabet.org>
	<52E748CE.9050504@oracle.com> <52E75DB7.6040307@oracle.com>
Message-ID: <06D59013-8880-4968-B0B7-15650CBA44E2@oracle.com>

This looks like a JNI omission to me. JDWP uses JNI to invoke the method, but CallNonvirtualIntMethod() does not seem to handle default methods. When called with an interface method it will always lookup the virtual implementation (just like CallIntMethod() would do).

My very naive first shot at a fix is below. It seems to work for the example program in this email thread, but I don?t know what else it breaks.

JDK-8031195 will have the same problem when we try to implement that.

Thanks,
/Staffan

--- a/src/share/vm/prims/jni.cpp
+++ b/src/share/vm/prims/jni.cpp
@@ -1320,9 +1320,14 @@
       // interface call
       KlassHandle h_holder(THREAD, holder);

+      if (call_type == JNI_VIRTUAL) {
       int itbl_index = m->itable_index();
       Klass* k = h_recv->klass();
       selected_method = InstanceKlass::cast(k)->method_at_itable(h_holder(), itbl_index, CHECK);
+      } else {
+        assert(m->is_default_method(), "non virtual calls on interface methods must be on a default method");
+        selected_method = m;
+      }
     }
   }

On 28 jan 2014, at 08:35, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> Hi,
> 
> I think this is related to https://bugs.openjdk.java.net/browse/JDK-8031195 (com.sun.jdi.InterfaceType.invokeMethod() is missing)
> 
> -JB-
> 
> On 28.1.2014 07:06, David Holmes wrote:
>> Hi Jesper,
>> 
>> This seems more of an issue with the hotspot runtime so cc'd hotspot-dev.
>> 
>> David
>> 
>> On 27/01/2014 11:37 PM, Jesper Steen M?ller wrote:
>>> Hi list
>>> 
>>> I realize that this is possibly not the right list, but I'm having a
>>> lambda-related problem with the JDWP protocol (from the Eclipse Java
>>> Debugger)
>>> The problem is that I cannot invoke the default method of an interface
>>> using the equivalent of the superclass invocation syntax. Consider
>>> this example:
>>> 
>>> public interface A {
>>>    default int getOne() {
>>>        return 1;
>>>    }
>>> }
>>> 
>>> public interface B {
>>>    default int getOne() {
>>>        return 2;
>>>    }
>>> }
>>> 
>>> public class Impl implements A, B {
>>>    public int getOne() {
>>>        return B.super.getOne() + 3; // stop here and inspect
>>> B.super.getOne()
>>>    }
>>>    public static void main(String[] args) {
>>>        Impl i = new Impl();
>>>        System.out.println(i.getOne());
>>>    }
>>> }
>>> 
>>> Now, consider the line with the comment "stop here ...". Assume I have
>>> a suspended thread on that line, and I wish to inspect
>>> "B.super.getOne()", i.e. invoke the method B.getOne, using the 'this'
>>> reference as the receiver. So, I'm sending a "Invoke Method" command
>>> under the ObjectReference Command Set, like this:
>>> 
>>> object     -  objectID of 'this'
>>> thread       - threadID of suspended thread
>>> clazz         - classID of 'B'
>>> method     - methodID of 'B.getOne'
>>> arguments - 0
>>> option      - 3 (this INVOKE_SINGLE_THREADED +
>>> INVOKE_NONVIRTUALINVOKE_NONVIRTUAL)
>>> 
>>> However, the return value is '5' which indicates that the usual
>>> virtual call semantics were used on 'this'. Is this supposed to work?
>>> Have anyone tried this?
>>> 
>>> TIA,
>>> Jesper
>>> 
>>> 
> 


From mikael.gerdin at oracle.com  Tue Jan 28 06:01:12 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 28 Jan 2014 15:01:12 +0100
Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering problem
	with Conc refinement and card marking
Message-ID: <1596268.5X5t2hab6c@mgerdin03>

Hi all,

Please review this backport for the introduction of the StoreLoad barrier into 
G1's write barrier.

The patch from 8 does not apply cleanly to 7u60 since the MacroAssembler code 
was broken out of assembler_*.[ch]pp into macroAssembler_*.[ch]pp.
When I manually edited the patch file to apply the change to the assembler*-
files the patch applies with a line offset so the code has not been changed, 
just moved.

(this fix depends on JDK-8029335, however that change backports cleanly so as 
per the process no extra code review is required for the backport.)

Webrev: http://cr.openjdk.java.net/~mgerdin/8014555-backport/webrev.0
Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555

/Mikael

From zhengyu.gu at oracle.com  Tue Jan 28 05:47:14 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 28 Jan 2014 08:47:14 -0500
Subject: RFR(XS) 8032827: NMT: missing virtual memory tagging in
	os::workaround_expand_exec_shield_cs_limit()
In-Reply-To: <52E6D0B1.9060301@oracle.com>
References: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>
	<52E6D0B1.9060301@oracle.com>
Message-ID: <82B9EFD8-F142-4AE6-9BEE-DA035AB272B1@oracle.com>

Thanks for the review.

-Zhengyu

On Jan 27, 2014, at 4:33 PM, harold seigel wrote:

> Hi Zhengyu,
> 
> The change looks good.
> 
> Harold
> On 1/27/2014 3:17 PM, Zhengyu Gu wrote:
>> This is a simple fix for missing NMT tagging on virtual memory reserved in os::workaround_expand_exec_shield_cs_limit() function (Linux 32 only)
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032827
>> Webrev: http://cr.openjdk.java.net/~zgu/8032827/webrev.00/
>> 
>> 
>> Thanks,
>> 
>> -Zhengyu
>> 
> 


From zhengyu.gu at oracle.com  Tue Jan 28 05:47:31 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 28 Jan 2014 08:47:31 -0500
Subject: RFR(XS) 8032827: NMT: missing virtual memory tagging in
	os::workaround_expand_exec_shield_cs_limit()
In-Reply-To: <52E6D0B1.9060301@oracle.com>
References: <7C31D133-B6E6-4DA1-B4A5-CA10296E9BEC@oracle.com>
	<52E6D0B1.9060301@oracle.com>
Message-ID: <07892925-5E18-4453-8010-BF463F2D500C@oracle.com>

Thanks Coleen.

-Zhengyu

On Jan 27, 2014, at 4:33 PM, harold seigel wrote:

> Hi Zhengyu,
> 
> The change looks good.
> 
> Harold
> On 1/27/2014 3:17 PM, Zhengyu Gu wrote:
>> This is a simple fix for missing NMT tagging on virtual memory reserved in os::workaround_expand_exec_shield_cs_limit() function (Linux 32 only)
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032827
>> Webrev: http://cr.openjdk.java.net/~zgu/8032827/webrev.00/
>> 
>> 
>> Thanks,
>> 
>> -Zhengyu
>> 
> 


From bengt.rutisson at oracle.com  Tue Jan 28 07:25:57 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 28 Jan 2014 16:25:57 +0100
Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering
	problem with Conc refinement and card marking
In-Reply-To: <1596268.5X5t2hab6c@mgerdin03>
References: <1596268.5X5t2hab6c@mgerdin03>
Message-ID: <5E6E9263-417C-4260-A677-27CEAF83AACD@oracle.com>


Hi Mikael,

GC changes look good. But I guess they applied cleanely :)

Bengt

> 28 jan 2014 kl. 15:01 skrev Mikael Gerdin <mikael.gerdin at oracle.com>:
> 
> Hi all,
> 
> Please review this backport for the introduction of the StoreLoad barrier into 
> G1's write barrier.
> 
> The patch from 8 does not apply cleanly to 7u60 since the MacroAssembler code 
> was broken out of assembler_*.[ch]pp into macroAssembler_*.[ch]pp.
> When I manually edited the patch file to apply the change to the assembler*-
> files the patch applies with a line offset so the code has not been changed, 
> just moved.
> 
> (this fix depends on JDK-8029335, however that change backports cleanly so as 
> per the process no extra code review is required for the backport.)
> 
> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555-backport/webrev.0
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555
> 
> /Mikael

From vladimir.kozlov at oracle.com  Tue Jan 28 15:49:43 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 28 Jan 2014 15:49:43 -0800
Subject: Hotspot part of PPC64 port was merged into jdk9
Message-ID: <52E84217.9090803@oracle.com>

It was pushed into Hotspot Compiler repository for additional testing:

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/

Hotspot changes:

8016476: PPC64 (part 1): reenable CORE build
8016491: PPC64 (part 2): Clean up PPC defines.
8016586: PPC64 (part 3): basic changes for PPC64
8017313: PPC64 (part 6): stack handling improvements
8017317: PPC64 (part 7): cppInterpreter: implement support for biased 
locking
8016696: PPC64 (part 4): add relocation for trampoline stubs
8019517: PPC64 (part 102): cppInterpreter: implement G1 support
8019518: PPC64 (part 103): cppInterpreter: implement support for 
compressed Oops
8019519: PPC64 (part 105): C interpreter: implement support for jvmti 
early return.
8020121: PPC64: fix build in cppInterpreter after 8019519
8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles
8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX.
8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64
8019972: PPC64 (part 9): platform files for interpreter only VM.
8020775: PPC64 (part 12): posix signal printing
8023033: PPC64 (part 13): basic changes for AIX
8024379: Adapt PPC64 port to 8003424
8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles
8023038: PPC64 (part 15): Platform files for AIX/PPC64 support
8024344: PPC64 (part 112): C argument in register AND stack slot.
8024469: PPC64 (part 202): cppInterpreter: support for OSR.
8024342: PPC64 (part 111): Support for C calling conventions that 
require 64-bit ints.
8024922: PPC64 (part 116): Extend adlc to generate fields into nodes.
8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling
8026487: PPC64: Implement 'os::fork_and_exec' on AIX
8027964: Adapt PPC to 6843347: Boundary values in some public GC options 
cause crashes
8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace 
concepts
8027966: Adapt PPC to 8023657: New type profiling points: arguments to call
8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic 
crashes the JVM
8027968: Adapt PPC to 8024927: Nashorn performance regression with 
CompressedOops
8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes 
after register allocation
8024921: PPC64 (part 113): Extend Load and Store nodes to know about 
memory ordering
8028401: PPC (part 117): Improve usability of adlc and format() 
functionality.
8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP 
on ppc64.
8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops 
has limited usefulness now'
8028580: PPC64 (part 114/120): Support for Call nodes with constants.
8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization.
8028767: PPC64: (part 121): smaller shared changes needed to build C2
8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object.
8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence.
8029015: PPC64 (part 216): opto: trap based null and range checks
8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function 
descriptor tables
8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
8029888: PPC64: (part 219): adl replacement variable CondRegister
8029940: PPC64 (part 122): C2 compiler port
8029957: PPC64 (part 213): cppInterpreter: memory ordering for object 
initialization
8030863: PPC64: (part 220): ConstantTableBase for calls between args and 
jvms
8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and 
range checks
8031319: PPC64: Some fixes in ppc and aix coding.
8029101: PPC64 (part 211): ordering of Independent Reads of Independent 
Writes
8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state.
8029941: rollback changes in make/jprt.properties for embedded testing

From david.holmes at oracle.com  Tue Jan 28 15:55:46 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Jan 2014 09:55:46 +1000
Subject: Hotspot part of PPC64 port was merged into jdk9
In-Reply-To: <52E84217.9090803@oracle.com>
References: <52E84217.9090803@oracle.com>
Message-ID: <52E84382.70609@oracle.com>

On 29/01/2014 9:49 AM, Vladimir Kozlov wrote:
> It was pushed into Hotspot Compiler repository for additional testing:
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/

That's a big milestone! Thanks Vladimir!

And thanks Goetz for your patience through all this.

David
-----

> Hotspot changes:
>
> 8016476: PPC64 (part 1): reenable CORE build
> 8016491: PPC64 (part 2): Clean up PPC defines.
> 8016586: PPC64 (part 3): basic changes for PPC64
> 8017313: PPC64 (part 6): stack handling improvements
> 8017317: PPC64 (part 7): cppInterpreter: implement support for biased
> locking
> 8016696: PPC64 (part 4): add relocation for trampoline stubs
> 8019517: PPC64 (part 102): cppInterpreter: implement G1 support
> 8019518: PPC64 (part 103): cppInterpreter: implement support for
> compressed Oops
> 8019519: PPC64 (part 105): C interpreter: implement support for jvmti
> early return.
> 8020121: PPC64: fix build in cppInterpreter after 8019519
> 8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles
> 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX.
> 8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64
> 8019972: PPC64 (part 9): platform files for interpreter only VM.
> 8020775: PPC64 (part 12): posix signal printing
> 8023033: PPC64 (part 13): basic changes for AIX
> 8024379: Adapt PPC64 port to 8003424
> 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles
> 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support
> 8024344: PPC64 (part 112): C argument in register AND stack slot.
> 8024469: PPC64 (part 202): cppInterpreter: support for OSR.
> 8024342: PPC64 (part 111): Support for C calling conventions that
> require 64-bit ints.
> 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes.
> 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling
> 8026487: PPC64: Implement 'os::fork_and_exec' on AIX
> 8027964: Adapt PPC to 6843347: Boundary values in some public GC options
> cause crashes
> 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace
> concepts
> 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call
> 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic
> crashes the JVM
> 8027968: Adapt PPC to 8024927: Nashorn performance regression with
> CompressedOops
> 8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes
> after register allocation
> 8024921: PPC64 (part 113): Extend Load and Store nodes to know about
> memory ordering
> 8028401: PPC (part 117): Improve usability of adlc and format()
> functionality.
> 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP
> on ppc64.
> 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops
> has limited usefulness now'
> 8028580: PPC64 (part 114/120): Support for Call nodes with constants.
> 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization.
> 8028767: PPC64: (part 121): smaller shared changes needed to build C2
> 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile
> object.
> 8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence.
> 8029015: PPC64 (part 216): opto: trap based null and range checks
> 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function
> descriptor tables
> 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
> 8029888: PPC64: (part 219): adl replacement variable CondRegister
> 8029940: PPC64 (part 122): C2 compiler port
> 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object
> initialization
> 8030863: PPC64: (part 220): ConstantTableBase for calls between args and
> jvms
> 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and
> range checks
> 8031319: PPC64: Some fixes in ppc and aix coding.
> 8029101: PPC64 (part 211): ordering of Independent Reads of Independent
> Writes
> 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state.
> 8029941: rollback changes in make/jprt.properties for embedded testing

From azeem.jiva at oracle.com  Tue Jan 28 16:00:51 2014
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Tue, 28 Jan 2014 16:00:51 -0800
Subject: Hotspot part of PPC64 port was merged into jdk9
In-Reply-To: <52E84217.9090803@oracle.com>
References: <52E84217.9090803@oracle.com>
Message-ID: <BB25B4C0-6ADC-4390-91F5-A7E109DBC256@oracle.com>

Congrats on this huge accomplishment!

--
Azeem Jiva
@javawithjiva

On Jan 28, 2014, at 3:49 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> It was pushed into Hotspot Compiler repository for additional testing:
> 
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/
> 
> Hotspot changes:
> 
> 8016476: PPC64 (part 1): reenable CORE build
> 8016491: PPC64 (part 2): Clean up PPC defines.
> 8016586: PPC64 (part 3): basic changes for PPC64
> 8017313: PPC64 (part 6): stack handling improvements
> 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking
> 8016696: PPC64 (part 4): add relocation for trampoline stubs
> 8019517: PPC64 (part 102): cppInterpreter: implement G1 support
> 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops
> 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return.
> 8020121: PPC64: fix build in cppInterpreter after 8019519
> 8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles
> 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX.
> 8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64
> 8019972: PPC64 (part 9): platform files for interpreter only VM.
> 8020775: PPC64 (part 12): posix signal printing
> 8023033: PPC64 (part 13): basic changes for AIX
> 8024379: Adapt PPC64 port to 8003424
> 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles
> 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support
> 8024344: PPC64 (part 112): C argument in register AND stack slot.
> 8024469: PPC64 (part 202): cppInterpreter: support for OSR.
> 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints.
> 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes.
> 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling
> 8026487: PPC64: Implement 'os::fork_and_exec' on AIX
> 8027964: Adapt PPC to 6843347: Boundary values in some public GC options cause crashes
> 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts
> 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call
> 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM
> 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops
> 8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes after register allocation
> 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering
> 8028401: PPC (part 117): Improve usability of adlc and format() functionality.
> 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64.
> 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now'
> 8028580: PPC64 (part 114/120): Support for Call nodes with constants.
> 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization.
> 8028767: PPC64: (part 121): smaller shared changes needed to build C2
> 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object.
> 8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence.
> 8029015: PPC64 (part 216): opto: trap based null and range checks
> 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function descriptor tables
> 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
> 8029888: PPC64: (part 219): adl replacement variable CondRegister
> 8029940: PPC64 (part 122): C2 compiler port
> 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
> 8030863: PPC64: (part 220): ConstantTableBase for calls between args and jvms
> 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks
> 8031319: PPC64: Some fixes in ppc and aix coding.
> 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes
> 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state.
> 8029941: rollback changes in make/jprt.properties for embedded testing


From alejandro.murillo at oracle.com  Tue Jan 28 16:07:12 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Wed, 29 Jan 2014 00:07:12 +0000
Subject: hg: hsx/hsx25/hotspot: 6 new changesets
Message-ID: <20140129000746.729A56282F@hg.openjdk.java.net>

Changeset: 9a11d5e679cf
Author:    katleman
Date:      2014-01-24 15:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9a11d5e679cf

Added tag jdk8-b126 for changeset c8218f1072a0

! .hgtags

Changeset: 58879cd9f8df
Author:    amurillo
Date:      2014-01-28 09:51 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/58879cd9f8df

Merge

! .hgtags

Changeset: 7e412f95e310
Author:    amurillo
Date:      2014-01-23 13:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7e412f95e310

8032608: new hotspot build - hs25-b69
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 2185d483f5f8
Author:    kvn
Date:      2014-01-27 10:20 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2185d483f5f8

8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib)
Summary: Switch off EliminateAutoBox flag by default in jdk8 release.
Reviewed-by: iveresov

! src/share/vm/opto/c2_globals.hpp

Changeset: 32f017489ba5
Author:    amurillo
Date:      2014-01-28 15:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/32f017489ba5

Merge


Changeset: 1d8728efc05f
Author:    amurillo
Date:      2014-01-28 15:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1d8728efc05f

Added tag hs25-b69 for changeset 32f017489ba5

! .hgtags


From alejandro.murillo at oracle.com  Tue Jan 28 16:53:24 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Wed, 29 Jan 2014 00:53:24 +0000
Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets
Message-ID: <20140129005359.8D89D62833@hg.openjdk.java.net>

Changeset: 9a11d5e679cf
Author:    katleman
Date:      2014-01-24 15:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9a11d5e679cf

Added tag jdk8-b126 for changeset c8218f1072a0

! .hgtags

Changeset: 58879cd9f8df
Author:    amurillo
Date:      2014-01-28 09:51 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/58879cd9f8df

Merge

! .hgtags

Changeset: 32f017489ba5
Author:    amurillo
Date:      2014-01-28 15:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/32f017489ba5

Merge


Changeset: 1d8728efc05f
Author:    amurillo
Date:      2014-01-28 15:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d8728efc05f

Added tag hs25-b69 for changeset 32f017489ba5

! .hgtags

Changeset: 54f0c207dc35
Author:    amurillo
Date:      2014-01-28 15:11 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/54f0c207dc35

8032984: new hotspot build - hs25-b70
Reviewed-by: jcoomes

! make/hotspot_version


From vladimir.kozlov at oracle.com  Tue Jan 28 20:27:25 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 28 Jan 2014 20:27:25 -0800
Subject: JDK part of PPC64 port was merged into jdk9
In-Reply-To: <52E851F7.6060603@oracle.com>
References: <52E851F7.6060603@oracle.com>
Message-ID: <52E8832D.6020805@oracle.com>

JDK changes also pushed into hs-comp forest which now has all ppc64 changes:

http://hg.openjdk.java.net/jdk9/hs-comp

Regards,
Vladimir

On 1/28/14 4:57 PM, Vladimir Kozlov wrote:
> It was pushed into jdk9/dev forest:
>
> http://hg.openjdk.java.net/jdk9/dev
>
> Hotspot part of the port was pushed into jdk9/hs-comp/hotspot
>
> JDK changes:
>
> 8017568: PPC64: Generic build preparations needed to enable new build on
> Linux/PPC64
> 8024265: Enable new build on AIX
> 8024900: PPC64: Enable new build on AIX (jdk part)
> 8028066: PPC64: 8025715 changes broke AIX build after sync
> 8024854: PPC64: Basic changes and files to build the class library on AIX
> 8029669: PPC64: 8027566 changes broke AIX build after sync
> 8028537: PPC64: Updated the JDK regression tests to run on AIX
> 8031134: PPC64: implement printing on AIX
> 8031997: PPC64: Make the various POLL constants system dependant
> 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

From volker.simonis at gmail.com  Tue Jan 28 21:40:52 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 29 Jan 2014 06:40:52 +0100
Subject: JDK part of PPC64 port was merged into jdk9
In-Reply-To: <52E8832D.6020805@oracle.com>
References: <52E851F7.6060603@oracle.com>
	<52E8832D.6020805@oracle.com>
Message-ID: <CA+3eh13oN0s+Ri0Sj7s7FdeQ-5uPZa8FTQ8=uTW3YtX9PLFthA@mail.gmail.com>

Thanks Vladimir,

all this wouldn't have been possible without your help!

Regards,
Volker

On Wednesday, January 29, 2014, Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> JDK changes also pushed into hs-comp forest which now has all ppc64
> changes:
>
> http://hg.openjdk.java.net/jdk9/hs-comp
>
> Regards,
> Vladimir
>
> On 1/28/14 4:57 PM, Vladimir Kozlov wrote:
>
>> It was pushed into jdk9/dev forest:
>>
>> http://hg.openjdk.java.net/jdk9/dev
>>
>> Hotspot part of the port was pushed into jdk9/hs-comp/hotspot
>>
>> JDK changes:
>>
>> 8017568: PPC64: Generic build preparations needed to enable new build on
>> Linux/PPC64
>> 8024265: Enable new build on AIX
>> 8024900: PPC64: Enable new build on AIX (jdk part)
>> 8028066: PPC64: 8025715 changes broke AIX build after sync
>> 8024854: PPC64: Basic changes and files to build the class library on AIX
>> 8029669: PPC64: 8027566 changes broke AIX build after sync
>> 8028537: PPC64: Updated the JDK regression tests to run on AIX
>> 8031134: PPC64: implement printing on AIX
>> 8031997: PPC64: Make the various POLL constants system dependant
>> 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests
>>
>

From goetz.lindenmaier at sap.com  Wed Jan 29 03:50:13 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 29 Jan 2014 11:50:13 +0000
Subject: RFR (XS): 8033117: PPC64: Adapt to 8002074: Support for AES on SPARC
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap>

Hi,

The ppc port must implement Matcher::pass_original_key_for_aes() introduced to
jdk9 after the last merge to the staging repo.

Please review
http://cr.openjdk.java.net/~goetz/webrevs/8033117-1-aes/
for jdk9/hs-comp and also for downport to ppc-aix-port/stage which will
be integrated to jdk8u at some point.

The change affects only ppc64 files.

Thanks and best regards,
  Goetz.

From staffan.larsen at oracle.com  Wed Jan 29 05:17:34 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 29 Jan 2014 14:17:34 +0100
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
Message-ID: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>

This is a more formal review request for the patch proposed in [0]

webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8033126

The bug report has a reproducer/testcase that I have used to verify the fix. I have also run the vm/jni tests in the JCK.

Thanks,
/Staffan

[0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html

From stefan.johansson at oracle.com  Wed Jan 29 05:54:17 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 29 Jan 2014 14:54:17 +0100
Subject: RFR: 8028498:
	runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
	asserts in RT_Baseline
Message-ID: <52E90809.3000900@oracle.com>

Hi,

Please review this fix for:
https://bugs.openjdk.java.net/browse/JDK-8028498

Webrev:
http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/

Summary:
The initial young generation size has been fairly small by default 
(1.5M) and if setting ObjectAlignmentInBytes to something larger than 
the default it can causes CDS to trigger a GC when dumping the archive. 
At this point the VM is not ready to handle a GC and we will hit an 
assertion. Making sure we can handle a GC at this point is not trivial 
and the proposed solution is to alter the default sizing of the young 
generation as well as adding a safety check when dumping the archive to 
exit the VM if the young generation is too small.

Testing:
* JPRT build and test passes
* Failing test now passes on all platforms (tested throught JPRT)
* Verified that the GC and Runtime jtreg tests still passes

Cheers,
Stefan

From karen.kinnear at oracle.com  Wed Jan 29 06:28:11 2014
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 29 Jan 2014 09:28:11 -0500
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
In-Reply-To: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
References: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
Message-ID: <E19F858F-A77C-402F-9050-A27CF43DAFF6@oracle.com>

Staffan,

Fix approach looks good. Can you please remove the assertion - I don't think that will always
be true.

Can you please submit an automated testcase with this?

thanks,
Karen

On Jan 29, 2014, at 8:17 AM, Staffan Larsen wrote:

> This is a more formal review request for the patch proposed in [0]
> 
> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8033126
> 
> The bug report has a reproducer/testcase that I have used to verify the fix. I have also run the vm/jni tests in the JCK.
> 
> Thanks,
> /Staffan
> 
> [0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html


From thomas.schatzl at oracle.com  Wed Jan 29 06:58:24 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 29 Jan 2014 15:58:24 +0100
Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering
	problem with Conc refinement and card marking
In-Reply-To: <1596268.5X5t2hab6c@mgerdin03>
References: <1596268.5X5t2hab6c@mgerdin03>
Message-ID: <1391007504.2593.32.camel@cirrus>

Hi Mikael,

On Tue, 2014-01-28 at 15:01 +0100, Mikael Gerdin wrote:
> Hi all,
> 
> Please review this backport for the introduction of the StoreLoad barrier into 
> G1's write barrier.
> 
> The patch from 8 does not apply cleanly to 7u60 since the MacroAssembler code 
> was broken out of assembler_*.[ch]pp into macroAssembler_*.[ch]pp.
> When I manually edited the patch file to apply the change to the assembler*-
> files the patch applies with a line offset so the code has not been changed, 
> just moved.
> 
> (this fix depends on JDK-8029335, however that change backports cleanly so as 
> per the process no extra code review is required for the backport.)

  as far as I can see it looks good.

Thomas



From jesper.wilhelmsson at oracle.com  Wed Jan 29 07:06:57 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 29 Jan 2014 16:06:57 +0100
Subject: RFR: 8028498:
	runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
	asserts in RT_Baseline
In-Reply-To: <52E90809.3000900@oracle.com>
References: <52E90809.3000900@oracle.com>
Message-ID: <52E91911.6070603@oracle.com>

Looks good!
/Jesper

Stefan Johansson skrev 29/1/14 2:54 PM:
> Hi,
>
> Please review this fix for:
> https://bugs.openjdk.java.net/browse/JDK-8028498
>
> Webrev:
> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/
>
> Summary:
> The initial young generation size has been fairly small by default (1.5M) and if
> setting ObjectAlignmentInBytes to something larger than the default it can
> causes CDS to trigger a GC when dumping the archive. At this point the VM is not
> ready to handle a GC and we will hit an assertion. Making sure we can handle a
> GC at this point is not trivial and the proposed solution is to alter the
> default sizing of the young generation as well as adding a safety check when
> dumping the archive to exit the VM if the young generation is too small.
>
> Testing:
> * JPRT build and test passes
> * Failing test now passes on all platforms (tested throught JPRT)
> * Verified that the GC and Runtime jtreg tests still passes
>
> Cheers,
> Stefan

From coleen.phillimore at oracle.com  Wed Jan 29 08:07:29 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 29 Jan 2014 11:07:29 -0500
Subject: RFR: 8028498:
	runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
	asserts in RT_Baseline
In-Reply-To: <52E90809.3000900@oracle.com>
References: <52E90809.3000900@oracle.com>
Message-ID: <52E92741.8060900@oracle.com>


Stefan,

I think you should go the other way.  If DumpSharedSpaces, ignore 
options for NewSize etc and still create the archive.

Coleen

On 1/29/14 8:54 AM, Stefan Johansson wrote:
> Hi,
>
> Please review this fix for:
> https://bugs.openjdk.java.net/browse/JDK-8028498
>
> Webrev:
> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/
>
> Summary:
> The initial young generation size has been fairly small by default 
> (1.5M) and if setting ObjectAlignmentInBytes to something larger than 
> the default it can causes CDS to trigger a GC when dumping the 
> archive. At this point the VM is not ready to handle a GC and we will 
> hit an assertion. Making sure we can handle a GC at this point is not 
> trivial and the proposed solution is to alter the default sizing of 
> the young generation as well as adding a safety check when dumping the 
> archive to exit the VM if the young generation is too small.
>
> Testing:
> * JPRT build and test passes
> * Failing test now passes on all platforms (tested throught JPRT)
> * Verified that the GC and Runtime jtreg tests still passes
>
> Cheers,
> Stefan


From stefan.johansson at oracle.com  Wed Jan 29 08:30:25 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 29 Jan 2014 17:30:25 +0100
Subject: RFR: 8028498:
	runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
	asserts in RT_Baseline
In-Reply-To: <52E92741.8060900@oracle.com>
References: <52E90809.3000900@oracle.com> <52E92741.8060900@oracle.com>
Message-ID: <52E92CA1.4060604@oracle.com>

Thanks for looking at this Coleen,

So you would prefer us to have some heap setting that "should always 
work" and apply that if we see that DumpSharedSpaces is true? I'm not 
sure which solution I like best but I can take a look at it tomorrow and 
see how such a solution would work.

Stefan

On 2014-01-29 17:07, Coleen Phillimore wrote:
>
> Stefan,
>
> I think you should go the other way.  If DumpSharedSpaces, ignore 
> options for NewSize etc and still create the archive.
>
> Coleen
>
> On 1/29/14 8:54 AM, Stefan Johansson wrote:
>> Hi,
>>
>> Please review this fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8028498
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/
>>
>> Summary:
>> The initial young generation size has been fairly small by default 
>> (1.5M) and if setting ObjectAlignmentInBytes to something larger than 
>> the default it can causes CDS to trigger a GC when dumping the 
>> archive. At this point the VM is not ready to handle a GC and we will 
>> hit an assertion. Making sure we can handle a GC at this point is not 
>> trivial and the proposed solution is to alter the default sizing of 
>> the young generation as well as adding a safety check when dumping 
>> the archive to exit the VM if the young generation is too small.
>>
>> Testing:
>> * JPRT build and test passes
>> * Failing test now passes on all platforms (tested throught JPRT)
>> * Verified that the GC and Runtime jtreg tests still passes
>>
>> Cheers,
>> Stefan
>


From vladimir.kozlov at oracle.com  Wed Jan 29 08:45:20 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Jan 2014 08:45:20 -0800
Subject: RFR (XS): 8033117: PPC64: Adapt to 8002074: Support for AES on
	SPARC
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap>
Message-ID: <52E93020.6050705@oracle.com>

Thanks, Goetz

Changes are good. I will push it today. 8002074 is not in 8u20 yet so no need backport for now.

Thanks,
Vladimir

On 1/29/14 3:50 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> The ppc port must implement Matcher::pass_original_key_for_aes() introduced to
> jdk9 after the last merge to the staging repo.
>
> Please review
> http://cr.openjdk.java.net/~goetz/webrevs/8033117-1-aes/
> for jdk9/hs-comp and also for downport to ppc-aix-port/stage which will
> be integrated to jdk8u at some point.
>
> The change affects only ppc64 files.
>
> Thanks and best regards,
>    Goetz.
>

From Miroslaw.Niemiec at Oracle.COM  Wed Jan 29 15:18:20 2014
From: Miroslaw.Niemiec at Oracle.COM (Miroslaw Niemiec)
Date: Wed, 29 Jan 2014 15:18:20 -0800
Subject: [8022452] Hotspot needs to know about Windows 8.1 and Windows Server
	2012 R2
Message-ID: <52E98C3C.3060007@Oracle.COM>


Hello!

I'd like to ask for review and approval for a direct back port from 8 to 7

Can I ask to expedite the review since

changes in
void os::win32::print_windows_version(outputStream* st)
applied with _no modification_  to jdk7

and there is no difference in
os::win32::print_windows_version()
between jdk8 and jdk7

This fix also needs to be done to complete a fix
for another CR: JDK-8020191
System.getProperty( " os.name " ) returns " Windows NT (unknown) " on 
Windows 8.1


This CR:
https://bugs.openjdk.java.net/browse/JDK-8022452

webrev for 7 (I am asking for review and approval):
http://cr.openjdk.java.net/~miroslawzn/8022452/webrev.01/ 
<http://cr.openjdk.java.net/%7Emiroslawzn/8022452/webrev.01/>


Original webrev for jdk8:
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/98aa538fd97e


Thank you
Miroslaw

From christian.tornqvist at oracle.com  Wed Jan 29 16:23:34 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Wed, 29 Jan 2014 19:23:34 -0500
Subject: [8022452] Hotspot needs to know about Windows 8.1 and Windows
	Server	2012 R2
In-Reply-To: <52E98C3C.3060007@Oracle.COM>
References: <52E98C3C.3060007@Oracle.COM>
Message-ID: <00d901cf1d51$83c00630$8b401290$@oracle.com>

Looks good!

Thanks,
Christian 

-----Original Message-----
From: hotspot-dev-bounces at openjdk.java.net
[mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Miroslaw Niemiec
Sent: Wednesday, January 29, 2014 6:18 PM
To: hotspot-dev at openjdk.java.net
Cc: Alejandro E Murillo
Subject: [8022452] Hotspot needs to know about Windows 8.1 and Windows
Server 2012 R2


Hello!

I'd like to ask for review and approval for a direct back port from 8 to 7

Can I ask to expedite the review since

changes in
void os::win32::print_windows_version(outputStream* st) applied with _no
modification_  to jdk7

and there is no difference in
os::win32::print_windows_version()
between jdk8 and jdk7

This fix also needs to be done to complete a fix for another CR: JDK-8020191
System.getProperty( " os.name " ) returns " Windows NT (unknown) " on
Windows 8.1


This CR:
https://bugs.openjdk.java.net/browse/JDK-8022452

webrev for 7 (I am asking for review and approval):
http://cr.openjdk.java.net/~miroslawzn/8022452/webrev.01/ 
<http://cr.openjdk.java.net/%7Emiroslawzn/8022452/webrev.01/>


Original webrev for jdk8:
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/98aa538fd97e


Thank you
Miroslaw


From belliottsmith at datastax.com  Wed Jan 29 16:45:41 2014
From: belliottsmith at datastax.com (Benedict Elliott Smith)
Date: Thu, 30 Jan 2014 00:45:41 +0000
Subject: Escape Analysis and Stack Allocation
In-Reply-To: <52E74954.9050608@oracle.com>
References: <CAFqWSgcdXOz+Fb_4-tzJnX57rO_RhUtqM51E=FOrVCShguN65w@mail.gmail.com>
	<52E56F6B.4060202@infinite-source.de>
	<CAPYFHW11hXbZ-Epd3x_MJGhASX8HGqRjq+B9O4Pv4L2ynaP5mA@mail.gmail.com>
	<52E74954.9050608@oracle.com>
Message-ID: <CAFqWSgfT2srRaiLu3qZRTBn29L-WFSxX85==ttqpCA99O70MJQ@mail.gmail.com>

I'd definitely be interested if you could dig it out, especially if you
have the commit you forked from to compare against so I can figure out what
you changed and why. This approach seems just (or almost) as good to me, if
we can eliminate the problem you mention by, e.g. creating a special region
as Jeremy suggested. It also sounds a lot less involved to get to a
position to trial it, which is a huge plus.


On 28 January 2014 06:08, Vladimir Kozlov <vladimir.kozlov at oracle.com>wrote:

> I did the same experiment 4 years ago, back in jdk6 era. Called it MLAB,
> method local allocation buffer, works like thread local stack for
> non-escaping objects but was allocated in java heap as special TLAB. Got it
> worked but did not see benefits in jbb2005. GC requires no holes in heap,
> as result I had to give the buffer back to GC when young gen collection was
> needed. After GC a thread get new MLAB and starts allocation from scratch
> which nullified performance benefits.
>
> I can try to find those changes if someone interested.
>
> Regards,
> Vladimir
>
>
> On 1/27/14 9:21 PM, Jeremy Manson wrote:
>
>> I tried implementing direct stack allocation in Hotspot a couple of years
>> ago.  It was a pain to try to allocate anything outside the heap - there
>> are a lot of checks to make sure that your objects live on the heap.
>>
>> I ended up creating TLAB-like regions in the heap that could hold objects
>> allocated in a stack-like way.  It was a lot easier that way, and seemed
>> to
>> give the kinds of performance benefits you would expect.
>>
>> I never got around to trying to wire it up to Hotspot's escape analysis,
>> but it was a fairly obvious next step.
>>
>> Jeremy
>>
>>
>> On Sun, Jan 26, 2014 at 12:26 PM, Aaron Grunthal <
>> aaron.grunthal at infinite-source.de> wrote:
>>
>>  There also is an issue with merge points [1] which prevents objects in
>>> loops with an accumulator (e.g. reduce operations on streams) to
>>> stack-allocate the intermediate values.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-6853701
>>>
>>> - Aaron
>>>
>>>
>>> On 26.01.2014 07:04, Benedict Elliott Smith wrote:
>>>
>>>  Hi,
>>>>
>>>> I was digging into some (to me) unexpected behaviour of escape analysis,
>>>> namely that some references that clearly weren't escaping, and easily
>>>> determined to be so, were not being stack allocated.
>>>>
>>>> So, after some digging through the hotspot code, I discovered some
>>>> things
>>>> that were probably obvious to everyone on this list, but also some
>>>> things
>>>> I'm still a little perplexed about. I was hoping somebody could
>>>> enlighten
>>>> me about the latter.
>>>>
>>>> 1) I cannot see a reason why stores to a primitive array, for instance,
>>>> should cause the argument to escape in bcEscapeAnalyser.cpp
>>>> *iterate_one_block()*; most interestingly, a store to an object array
>>>> does
>>>> not result in this, which seems incongruous;
>>>>
>>>> 2) An object array store *does* however result in *set_global_escape()*
>>>> for
>>>> the value being stored, which makes sense, except that this should only
>>>> be
>>>> *set_method_escape()*, as per the paper, in the case where the target
>>>> array
>>>> is one of the method arguments. This seems to be missing, here and for
>>>> *putfield*.
>>>>
>>>> Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc.
>>>> The
>>>> fact that these all result in *set_method_escape()*, and that
>>>> *putfield*and
>>>> *aastore* don't optimise *set_global_escape()* to
>>>> *set_method_escape()*where possible, seem to point to the conclusion
>>>> that *_is_arg_stack
>>>> / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is
>>>> this the case? If so, why the confusing name?*
>>>>
>>>>
>>>> Which leads to a much trickier but more interesting question, which is:
>>>> what are the barriers to performing actual stack allocation of full
>>>> objects, instead of scalar replacement? It is something I would be keen
>>>> to
>>>> investigate, but given my lack of familiarity with the codebase, it
>>>> would
>>>> be immensely helpful to hear what the major difficulties / showstoppers
>>>> might be before trying to attack it.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Benedict
>>>>
>>>>
>>>> *I do note that in escape.cpp *ArgEscape* is defined and is explicitly
>>>> overloaded to include some of the characteristics of
>>>> *is_scalar_replaceable*.
>>>> However the *is_arg_stack()* method is commented with "The given
>>>> argument
>>>> escapes the callee, but does not become globally reachable." which seems
>>>> to
>>>> correspond to *ArgEscape* in the paper, but only *invoke()* seems to
>>>> follow
>>>> the spec, when invoking a method that cannot be analysed, and this would
>>>> also be true for *!is_scalar_replaceable.*
>>>>
>>>>
>>>>
>>>

From david.holmes at oracle.com  Wed Jan 29 16:51:11 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jan 2014 10:51:11 +1000
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
In-Reply-To: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
References: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
Message-ID: <52E9A1FF.1030401@oracle.com>

Hi Staffan,

On 29/01/2014 11:17 PM, Staffan Larsen wrote:
> This is a more formal review request for the patch proposed in [0]
>
> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8033126
>
> The bug report has a reproducer/testcase that I have used to verify the fix. I have also run the vm/jni tests in the JCK.

This whole scenario doesn't look right to me. You can't arbitrarily 
invoke default methods in a class hierarchy. Given the testcase:

interface A {
     default int getOne() {
         return 1;
     }
}

interface B extends A {
     default int getOne() {
         return 2;
     }
}

abstract class Abstract implements B {
}

class Impl extends Abstract {
     public int getOne() {
         return 3;
     }
}

class Impl2 extends Impl {
     public int getOne() {
         return 4;
     }
}

public class ImplTest {
     public static void main(String[] args) {
         System.loadLibrary("impl");
         Impl2 i = new Impl2();
         test(i);
     }
     static native void test(Impl i);
}

The only legitimate call is Impl2.getOne() which should return 4.

David
-----


> Thanks,
> /Staffan
>
> [0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html
>

From coleen.phillimore at oracle.com  Wed Jan 29 17:02:02 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 29 Jan 2014 20:02:02 -0500
Subject: [8022452] Hotspot needs to know about Windows 8.1 and Windows
	Server 2012 R2
In-Reply-To: <52E98C3C.3060007@Oracle.COM>
References: <52E98C3C.3060007@Oracle.COM>
Message-ID: <52E9A48A.6030503@oracle.com>


This looks good.
Coleen

On 1/29/14 6:18 PM, Miroslaw Niemiec wrote:
>
> Hello!
>
> I'd like to ask for review and approval for a direct back port from 8 
> to 7
>
> Can I ask to expedite the review since
>
> changes in
> void os::win32::print_windows_version(outputStream* st)
> applied with _no modification_  to jdk7
>
> and there is no difference in
> os::win32::print_windows_version()
> between jdk8 and jdk7
>
> This fix also needs to be done to complete a fix
> for another CR: JDK-8020191
> System.getProperty( " os.name " ) returns " Windows NT (unknown) " on 
> Windows 8.1
>
>
> This CR:
> https://bugs.openjdk.java.net/browse/JDK-8022452
>
> webrev for 7 (I am asking for review and approval):
> http://cr.openjdk.java.net/~miroslawzn/8022452/webrev.01/ 
> <http://cr.openjdk.java.net/%7Emiroslawzn/8022452/webrev.01/>
>
>
> Original webrev for jdk8:
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/98aa538fd97e
>
>
> Thank you
> Miroslaw


From staffan.larsen at oracle.com  Thu Jan 30 00:01:19 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 30 Jan 2014 09:01:19 +0100
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
In-Reply-To: <52E9A1FF.1030401@oracle.com>
References: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
	<52E9A1FF.1030401@oracle.com>
Message-ID: <BE4B36FC-DD26-4A7F-9984-15C4959DCF5B@oracle.com>


On 30 jan 2014, at 01:51, David Holmes <david.holmes at oracle.com> wrote:

> Hi Staffan,
> 
> On 29/01/2014 11:17 PM, Staffan Larsen wrote:
>> This is a more formal review request for the patch proposed in [0]
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8033126
>> 
>> The bug report has a reproducer/testcase that I have used to verify the fix. I have also run the vm/jni tests in the JCK.
> 
> This whole scenario doesn't look right to me. You can't arbitrarily invoke default methods in a class hierarchy. Given the testcase:
> 
> interface A {
>    default int getOne() {
>        return 1;
>    }
> }
> 
> interface B extends A {
>    default int getOne() {
>        return 2;
>    }
> }
> 
> abstract class Abstract implements B {
> }
> 
> class Impl extends Abstract {
>    public int getOne() {
>        return 3;
>    }
> }
> 
> class Impl2 extends Impl {
>    public int getOne() {
>        return 4;
>    }
> }
> 
> public class ImplTest {
>    public static void main(String[] args) {
>        System.loadLibrary("impl");
>        Impl2 i = new Impl2();
>        test(i);
>    }
>    static native void test(Impl i);
> }
> 
> The only legitimate call is Impl2.getOne() which should return 4.

What I am trying to mimic here (and which must be possible to do from JNI because debuggers need to do it) is the Java construct "B.super.getOne()? which you can call from anywhere B is implemented to actually call getOne() in B.

I think the CallNonvirtual<Type>Method()s are supposed to disregard the ?normal? virtual lookup of methods and allow the caller to pick and choose. 

"The CallNonvirtual<type>Method families of routines and the Call<type>Method families of routines are different. Call<type>Method routines invoke the method based on the class of the object, whileCallNonvirtual<type>Method routines invoke the method based on the class, designated by the clazz parameter, from which the method ID is obtained. The method ID must be obtained from the real class of the object or from one of its superclasses.?

Thanks,
/Staffan


> 
> David
> -----
> 
> 
>> Thanks,
>> /Staffan
>> 
>> [0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html
>> 


From mikael.gerdin at oracle.com  Thu Jan 30 01:10:16 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 30 Jan 2014 10:10:16 +0100
Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering
	problem with Conc refinement and card marking
In-Reply-To: <1596268.5X5t2hab6c@mgerdin03>
References: <1596268.5X5t2hab6c@mgerdin03>
Message-ID: <5823396.8n0bj8p6r9@mgerdin03>

Hi,

it would be great if someone with compiler knowledge could look through the 
assembler* and compiler changes in this change.
Thanks
/Mikael

On Tuesday 28 January 2014 15.01.12 you wrote:
> Hi all,
> 
> Please review this backport for the introduction of the StoreLoad barrier
> into G1's write barrier.
> 
> The patch from 8 does not apply cleanly to 7u60 since the MacroAssembler
> code was broken out of assembler_*.[ch]pp into macroAssembler_*.[ch]pp.
> When I manually edited the patch file to apply the change to the
> assembler*- files the patch applies with a line offset so the code has not
> been changed, just moved.
> 
> (this fix depends on JDK-8029335, however that change backports cleanly so
> as per the process no extra code review is required for the backport.)
> 
> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555-backport/webrev.0
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555
> 
> /Mikael


From roland.westrelin at oracle.com  Thu Jan 30 01:35:41 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 30 Jan 2014 10:35:41 +0100
Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering
	problem with Conc refinement and card marking
In-Reply-To: <5823396.8n0bj8p6r9@mgerdin03>
References: <1596268.5X5t2hab6c@mgerdin03> <5823396.8n0bj8p6r9@mgerdin03>
Message-ID: <4482B6CD-D740-457D-9FDF-522CA08CC57B@oracle.com>

Hi Mikael,

> it would be great if someone with compiler knowledge could look through the 
> assembler* and compiler changes in this change.

The assembler* and compiler changes look good.

Roland.


From mikael.gerdin at oracle.com  Thu Jan 30 02:11:19 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 30 Jan 2014 11:11:19 +0100
Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering
	problem with Conc refinement and card marking
In-Reply-To: <4482B6CD-D740-457D-9FDF-522CA08CC57B@oracle.com>
References: <1596268.5X5t2hab6c@mgerdin03> <5823396.8n0bj8p6r9@mgerdin03>
	<4482B6CD-D740-457D-9FDF-522CA08CC57B@oracle.com>
Message-ID: <3178981.H846CPx309@mgerdin03>

On Thursday 30 January 2014 10.35.41 Roland Westrelin wrote:
> Hi Mikael,
> 
> > it would be great if someone with compiler knowledge could look through
> > the
> > assembler* and compiler changes in this change.
> 
> The assembler* and compiler changes look good.

Thanks Roland.

/Mikael

> 
> Roland.


From david.holmes at oracle.com  Thu Jan 30 02:43:09 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jan 2014 20:43:09 +1000
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
In-Reply-To: <BE4B36FC-DD26-4A7F-9984-15C4959DCF5B@oracle.com>
References: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
	<52E9A1FF.1030401@oracle.com>
	<BE4B36FC-DD26-4A7F-9984-15C4959DCF5B@oracle.com>
Message-ID: <52EA2CBD.9000701@oracle.com>

Hi Staffan,

On 30/01/2014 6:01 PM, Staffan Larsen wrote:
>
> On 30 jan 2014, at 01:51, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>> Hi Staffan,
>>
>> On 29/01/2014 11:17 PM, Staffan Larsen wrote:
>>> This is a more formal review request for the patch proposed in [0]
>>>
>>> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033126
>>>
>>> The bug report has a reproducer/testcase that I have used to verify
>>> the fix. I have also run the vm/jni tests in the JCK.
>>
>> This whole scenario doesn't look right to me. You can't arbitrarily
>> invoke default methods in a class hierarchy. Given the testcase:
>>
>> interface A {
>>    default int getOne() {
>>        return 1;
>>    }
>> }
>>
>> interface B extends A {
>>    default int getOne() {
>>        return 2;
>>    }
>> }
>>
>> abstract class Abstract implements B {
>> }
>>
>> class Impl extends Abstract {
>>    public int getOne() {
>>        return 3;
>>    }
>> }
>>
>> class Impl2 extends Impl {
>>    public int getOne() {
>>        return 4;
>>    }
>> }
>>
>> public class ImplTest {
>>    public static void main(String[] args) {
>>        System.loadLibrary("impl");
>>        Impl2 i = new Impl2();
>>        test(i);
>>    }
>>    static native void test(Impl i);
>> }
>>
>> The only legitimate call is Impl2.getOne() which should return 4.
>
> What I am trying to mimic here (and which must be possible to do from
> JNI because debuggers need to do it) is the Java construct
> "B.super.getOne()? which you can call from anywhere B is implemented to
> actually call getOne() in B.
>
> I think the CallNonvirtual<Type>Method()s are supposed to disregard the
> ?normal? virtual lookup of methods and allow the caller to pick and choose.
>
> "The /CallNonvirtual<type>Method/ families of routines and the
> /Call<type>Method/ families of routines are different.
> /Call<type>Method/ routines invoke the method based on the class of the
> object, while/CallNonvirtual<type>Method/ routines invoke the method
> based on the class, designated by the |clazz| parameter, from which the
> method ID is obtained. The method ID must be obtained from the real
> class of the object or from one of its superclasses.?

Hmmmm. So this allows you to call any inherited version of the method on 
a given object regardless? If so then it seems we're throwing out the 
normal accessibility and overriding rules. I can see the need to be able 
to invoke super.foo() but this seems to give you the ability to 
effectively do super.super.foo() - which violates the language rules. If 
that is the case then allowing the same for default methods is 
consistent. But I'm troubled if this is indeed the case.

David

> Thanks,
> /Staffan
>
>
>>
>> David
>> -----
>>
>>
>>> Thanks,
>>> /Staffan
>>>
>>> [0]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html
>>>
>

From staffan.larsen at oracle.com  Thu Jan 30 03:39:53 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 30 Jan 2014 12:39:53 +0100
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
In-Reply-To: <52EA2CBD.9000701@oracle.com>
References: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
	<52E9A1FF.1030401@oracle.com>
	<BE4B36FC-DD26-4A7F-9984-15C4959DCF5B@oracle.com>
	<52EA2CBD.9000701@oracle.com>
Message-ID: <4228E81D-B12C-447E-A8F8-0E846FD4F908@oracle.com>


On 30 jan 2014, at 11:43, David Holmes <david.holmes at oracle.com> wrote:

> Hi Staffan,
> 
> On 30/01/2014 6:01 PM, Staffan Larsen wrote:
>> 
>> On 30 jan 2014, at 01:51, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>> 
>>> Hi Staffan,
>>> 
>>> On 29/01/2014 11:17 PM, Staffan Larsen wrote:
>>>> This is a more formal review request for the patch proposed in [0]
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033126
>>>> 
>>>> The bug report has a reproducer/testcase that I have used to verify
>>>> the fix. I have also run the vm/jni tests in the JCK.
>>> 
>>> This whole scenario doesn't look right to me. You can't arbitrarily
>>> invoke default methods in a class hierarchy. Given the testcase:
>>> 
>>> interface A {
>>>   default int getOne() {
>>>       return 1;
>>>   }
>>> }
>>> 
>>> interface B extends A {
>>>   default int getOne() {
>>>       return 2;
>>>   }
>>> }
>>> 
>>> abstract class Abstract implements B {
>>> }
>>> 
>>> class Impl extends Abstract {
>>>   public int getOne() {
>>>       return 3;
>>>   }
>>> }
>>> 
>>> class Impl2 extends Impl {
>>>   public int getOne() {
>>>       return 4;
>>>   }
>>> }
>>> 
>>> public class ImplTest {
>>>   public static void main(String[] args) {
>>>       System.loadLibrary("impl");
>>>       Impl2 i = new Impl2();
>>>       test(i);
>>>   }
>>>   static native void test(Impl i);
>>> }
>>> 
>>> The only legitimate call is Impl2.getOne() which should return 4.
>> 
>> What I am trying to mimic here (and which must be possible to do from
>> JNI because debuggers need to do it) is the Java construct
>> "B.super.getOne()? which you can call from anywhere B is implemented to
>> actually call getOne() in B.
>> 
>> I think the CallNonvirtual<Type>Method()s are supposed to disregard the
>> ?normal? virtual lookup of methods and allow the caller to pick and choose.
>> 
>> "The /CallNonvirtual<type>Method/ families of routines and the
>> /Call<type>Method/ families of routines are different.
>> /Call<type>Method/ routines invoke the method based on the class of the
>> object, while/CallNonvirtual<type>Method/ routines invoke the method
>> based on the class, designated by the |clazz| parameter, from which the
>> method ID is obtained. The method ID must be obtained from the real
>> class of the object or from one of its superclasses.?
> 
> Hmmmm. So this allows you to call any inherited version of the method on a given object regardless? If so then it seems we're throwing out the normal accessibility and overriding rules. I can see the need to be able to invoke super.foo() but this seems to give you the ability to effectively do super.super.foo() - which violates the language rules. If that is the case then allowing the same for default methods is consistent. But I'm troubled if this is indeed the case.

I believe this is indeed the case. And, yes, I want to extend it to default methods. JNI allows you to do stuff that you can?t normally do from Java.

/Staffan

> 
> David
> 
>> Thanks,
>> /Staffan
>> 
>> 
>>> 
>>> David
>>> -----
>>> 
>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>>> [0]
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html


From david.holmes at oracle.com  Thu Jan 30 04:12:44 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jan 2014 22:12:44 +1000
Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI
In-Reply-To: <4228E81D-B12C-447E-A8F8-0E846FD4F908@oracle.com>
References: <D58E0266-0423-4C9E-BE04-704613329B05@oracle.com>
	<52E9A1FF.1030401@oracle.com>
	<BE4B36FC-DD26-4A7F-9984-15C4959DCF5B@oracle.com>
	<52EA2CBD.9000701@oracle.com>
	<4228E81D-B12C-447E-A8F8-0E846FD4F908@oracle.com>
Message-ID: <52EA41BC.2080802@oracle.com>



On 30/01/2014 9:39 PM, Staffan Larsen wrote:
>
> On 30 jan 2014, at 11:43, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>> Hi Staffan,
>>
>> On 30/01/2014 6:01 PM, Staffan Larsen wrote:
>>>
>>> On 30 jan 2014, at 01:51, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>> Hi Staffan,
>>>>
>>>> On 29/01/2014 11:17 PM, Staffan Larsen wrote:
>>>>> This is a more formal review request for the patch proposed in [0]
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033126
>>>>>
>>>>> The bug report has a reproducer/testcase that I have used to verify
>>>>> the fix. I have also run the vm/jni tests in the JCK.
>>>>
>>>> This whole scenario doesn't look right to me. You can't arbitrarily
>>>> invoke default methods in a class hierarchy. Given the testcase:
>>>>
>>>> interface A {
>>>>   default int getOne() {
>>>>       return 1;
>>>>   }
>>>> }
>>>>
>>>> interface B extends A {
>>>>   default int getOne() {
>>>>       return 2;
>>>>   }
>>>> }
>>>>
>>>> abstract class Abstract implements B {
>>>> }
>>>>
>>>> class Impl extends Abstract {
>>>>   public int getOne() {
>>>>       return 3;
>>>>   }
>>>> }
>>>>
>>>> class Impl2 extends Impl {
>>>>   public int getOne() {
>>>>       return 4;
>>>>   }
>>>> }
>>>>
>>>> public class ImplTest {
>>>>   public static void main(String[] args) {
>>>>       System.loadLibrary("impl");
>>>>       Impl2 i = new Impl2();
>>>>       test(i);
>>>>   }
>>>>   static native void test(Impl i);
>>>> }
>>>>
>>>> The only legitimate call is Impl2.getOne() which should return 4.
>>>
>>> What I am trying to mimic here (and which must be possible to do from
>>> JNI because debuggers need to do it) is the Java construct
>>> "B.super.getOne()? which you can call from anywhere B is implemented to
>>> actually call getOne() in B.
>>>
>>> I think the CallNonvirtual<Type>Method()s are supposed to disregard the
>>> ?normal? virtual lookup of methods and allow the caller to pick and
>>> choose.
>>>
>>> "The /CallNonvirtual<type>Method/ families of routines and the
>>> /Call<type>Method/ families of routines are different.
>>> /Call<type>Method/ routines invoke the method based on the class of the
>>> object, while/CallNonvirtual<type>Method/ routines invoke the method
>>> based on the class, designated by the |clazz| parameter, from which the
>>> method ID is obtained. The method ID must be obtained from the real
>>> class of the object or from one of its superclasses.?
>>
>> Hmmmm. So this allows you to call any inherited version of the method
>> on a given object regardless? If so then it seems we're throwing out
>> the normal accessibility and overriding rules. I can see the need to
>> be able to invoke super.foo() but this seems to give you the ability
>> to effectively do super.super.foo() - which violates the language
>> rules. If that is the case then allowing the same for default methods
>> is consistent. But I'm troubled if this is indeed the case.
>
> I believe this is indeed the case. And, yes, I want to extend it to
> default methods. JNI allows you to do stuff that you can?t normally do
> from Java.

Indeed. I hadn't realized it was quite this liberal in allowing 
arbitrary method execution. Caveat Emptor.

In that case Reviewed.

Thanks,
David

> /Staffan
>
>>
>> David
>>
>>> Thanks,
>>> /Staffan
>>>
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> Thanks,
>>>>> /Staffan
>>>>>
>>>>> [0]
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html
>

From goetz.lindenmaier at sap.com  Thu Jan 30 06:26:51 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 30 Jan 2014 14:26:51 +0000
Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap>

Hi,

Please review and test this change:
http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn

It fixes the warnings with gcc 4.8  when compiling adlc
introduced in 8003854 with the ppc port.

This also needs to be downported to jdk8u via ppc-aix-port/stage.

Best regards,
  Goetz.


From vladimir.kozlov at oracle.com  Thu Jan 30 08:41:20 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 30 Jan 2014 08:41:20 -0800
Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap>
Message-ID: <52EA80B0.8060001@oracle.com>

Looks good. I will push it in both places.

Thanks,
Vladimir

On 1/30/14 6:26 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Please review and test this change:
> http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn
>
> It fixes the warnings with gcc 4.8  when compiling adlc
> introduced in 8003854 with the ppc port.
>
> This also needs to be downported to jdk8u via ppc-aix-port/stage.
>
> Best regards,
>    Goetz.
>

From kevin.walls at oracle.com  Thu Jan 30 12:27:40 2014
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Thu, 30 Jan 2014 20:27:40 +0000
Subject: hg: hsx/jdk7u/hotspot: 8020530: Non heap memory size calculated
	incorrectly
Message-ID: <20140130202744.8C255628DA@hg.openjdk.java.net>

Changeset: ad77e76008f3
Author:    vkempik
Date:      2014-01-30 19:53 +0400
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ad77e76008f3

8020530: Non heap memory size calculated incorrectly
Reviewed-by: coleenp, sla

! src/share/vm/services/management.cpp


From goetz.lindenmaier at sap.com  Thu Jan 30 14:28:22 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 30 Jan 2014 22:28:22 +0000
Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp
In-Reply-To: <52EA80B0.8060001@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap>
	<52EA80B0.8060001@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9172C@DEWDFEMB12A.global.corp.sap>

Thanks a lot!

Best regards,
  Goetz.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Thursday, January 30, 2014 5:41 PM
To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net
Subject: Re: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp

Looks good. I will push it in both places.

Thanks,
Vladimir

On 1/30/14 6:26 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Please review and test this change:
> http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn
>
> It fixes the warnings with gcc 4.8  when compiling adlc
> introduced in 8003854 with the ppc port.
>
> This also needs to be downported to jdk8u via ppc-aix-port/stage.
>
> Best regards,
>    Goetz.
>

From henry.jen at oracle.com  Thu Jan 30 14:54:33 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 30 Jan 2014 14:54:33 -0800
Subject: RFR: 8033057: clang: friend declaration specifying a default argument
	must be a definition
Message-ID: <52EAD829.1090506@oracle.com>

Hi,

Please review a fix on an error reported by clang 3.4.

http://cr.openjdk.java.net/~henryjen/jdk9/8033057/webrev/

The fix is to be comforming to C++ 11 spec, quoted,

C++11: ?8.3.6.4
"If a friend declaration specifies a default argument expression,
that declaration shall be a definition and shall be the only declaration
of the function or function template in the translation unit."

A working draft for C++ 11 can be found at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf

Cheers,
Henry

From henry.jen at oracle.com  Thu Jan 30 14:59:35 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 30 Jan 2014 14:59:35 -0800
Subject: RFR: 8033289: clang: clean up unused function warning
Message-ID: <52EAD957.7090503@oracle.com>

Hi,

Please review the fix that clean up unused function warning produced by 
clang 3.4.

http://cr.openjdk.java.net/~henryjen/jdk9/8033289/webrev/

One of those is used only in assert, so I wrapped it in #ifndef PRODUCT.

I had done a round of jprt along with other clang clean up, which passes 
all builds target.

Cheers,
Henry

From henry.jen at oracle.com  Thu Jan 30 15:11:37 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 30 Jan 2014 15:11:37 -0800
Subject: RFR: 8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized
	field _out
Message-ID: <52EADC29.60209@oracle.com>

Hi,

Please review a fix to disable uninitialized warning when build with 
clang 3.4,

http://cr.openjdk.java.net/~henryjen/jdk9/8033215/webrev/

This fix only disable the warning so that we can build with clang.

Cheers,
Henry

From alejandro.murillo at oracle.com  Thu Jan 30 15:36:18 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Thu, 30 Jan 2014 23:36:18 +0000
Subject: hg: hsx/jdk7u/hotspot: 2 new changesets
Message-ID: <20140130233625.252D8628F2@hg.openjdk.java.net>

Changeset: 4dfeceda1ba7
Author:    miroslawzn
Date:      2014-01-30 10:50 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4dfeceda1ba7

8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
Reviewed-by: coleenp, ctornqvi

! src/os/windows/vm/os_windows.cpp

Changeset: 8820d6ecaa4e
Author:    amurillo
Date:      2014-01-30 13:12 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/8820d6ecaa4e

Merge



From goetz.lindenmaier at sap.com  Thu Jan 30 23:24:38 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 31 Jan 2014 07:24:38 +0000
Subject: 8033057: clang: friend declaration specifying a default
	argument	must be a definition
In-Reply-To: <52EAD829.1090506@oracle.com>
References: <52EAD829.1090506@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CE917D3@DEWDFEMB12A.global.corp.sap>

Hi,

this was already fixed fort he ppc port in change
8023033: PPC64 (part 13): basic changes for AIX

See jdk9/hs-comp

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Henry Jen
Sent: Donnerstag, 30. Januar 2014 23:55
To: hotspot-dev at openjdk.java.net
Subject: RFR: 8033057: clang: friend declaration specifying a default argument must be a definition

Hi,

Please review a fix on an error reported by clang 3.4.

http://cr.openjdk.java.net/~henryjen/jdk9/8033057/webrev/

The fix is to be comforming to C++ 11 spec, quoted,

C++11: ?8.3.6.4
"If a friend declaration specifies a default argument expression,
that declaration shall be a definition and shall be the only declaration
of the function or function template in the translation unit."

A working draft for C++ 11 can be found at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf

Cheers,
Henry

From henry.jen at oracle.com  Thu Jan 30 23:50:39 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 30 Jan 2014 23:50:39 -0800
Subject: 8033057: clang: friend declaration specifying a default argument
	must be a definition
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE917D3@DEWDFEMB12A.global.corp.sap>
References: <52EAD829.1090506@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CE917D3@DEWDFEMB12A.global.corp.sap>
Message-ID: <52EB55CF.7070000@oracle.com>

Great, I closed the bug as a duplicate.

Cheers,
Henry

On 01/30/2014 11:24 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> this was already fixed fort he ppc port in change
> 8023033: PPC64 (part 13): basic changes for AIX
>
> See jdk9/hs-comp
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Henry Jen
> Sent: Donnerstag, 30. Januar 2014 23:55
> To: hotspot-dev at openjdk.java.net
> Subject: RFR: 8033057: clang: friend declaration specifying a default argument must be a definition
>
> Hi,
>
> Please review a fix on an error reported by clang 3.4.
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8033057/webrev/
>
> The fix is to be comforming to C++ 11 spec, quoted,
>
> C++11: ?8.3.6.4
> "If a friend declaration specifies a default argument expression,
> that declaration shall be a definition and shall be the only declaration
> of the function or function template in the translation unit."
>
> A working draft for C++ 11 can be found at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf
>
> Cheers,
> Henry
>

From mikael.gerdin at oracle.com  Fri Jan 31 01:11:20 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 31 Jan 2014 10:11:20 +0100
Subject: RFR: 8033289: clang: clean up unused function warning
In-Reply-To: <52EAD957.7090503@oracle.com>
References: <52EAD957.7090503@oracle.com>
Message-ID: <69560981.2P6taIEG9b@mgerdin03>

Hi,

On Thursday 30 January 2014 14.59.35 Henry Jen wrote:
> Hi,
> 
> Please review the fix that clean up unused function warning produced by
> clang 3.4.
> 
> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/webrev/
> 
> One of those is used only in assert, so I wrapped it in #ifndef PRODUCT.


2793 #ifndef PRODUCT
2794 // Function only used in assert, which will be disabled with NDEBUG
2795 // ??? Somehow NDEBUG is not working, use PRODUCT

This should be #ifdef ASSERT

Assertions in hotspot are compiled in when ASSERT is defined. It's a common 
mistake to mix usage of #ifndef PRODUCT and ASSERT.
We don't use NDEBUG in hotspot, I think you can skip the comment about the 
function being only used in an assert, that's quite common in the vm.

/Mikael


> 
> I had done a round of jprt along with other clang clean up, which passes
> all builds target.
> 
> Cheers,
> Henry


From thomas.schatzl at oracle.com  Fri Jan 31 03:00:24 2014
From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com)
Date: Fri, 31 Jan 2014 11:00:24 +0000
Subject: hg: hsx/jdk7u/hotspot: 3 new changesets
Message-ID: <20140131110033.7E3B46290D@hg.openjdk.java.net>

Changeset: c76437921025
Author:    tschatzl
Date:      2014-01-31 10:08 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c76437921025

8027476: Improve performance of Stringtable unlink
8027455: Improve symbol table scan times during gc pauses
Summary: Parallelize string table and symbol table scan during remark and full GC. Some additional statistics output if the experimental flag G1TraceStringSymbolTableScrubbing is set.
Reviewed-by: mgerdin, coleenp, brutisso

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: d2782fe9769e
Author:    tschatzl
Date:      2014-01-31 10:09 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d2782fe9769e

8027454: Do not traverse string table during G1 remark when treating them as strong roots during initial mark
Summary: Do not try to unlink string table entries unconditionally during remark. This is without side effects as the preceding initial mark always uses the string table as strong roots. Needs to be fixed with class unloading during concurrent mark.
Reviewed-by: brutisso, mgerdin

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: b6d3ebe42303
Author:    tschatzl
Date:      2014-01-31 10:09 +0100
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b6d3ebe42303

8032771: The flag VerifySilently misses a test case
Summary: Add test case for the VerifySilently flag.
Reviewed-by: brutisso

+ test/gc/TestVerifySilently.java


From dmitry.samersoff at oracle.com  Fri Jan 31 06:19:47 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 31 Jan 2014 18:19:47 +0400
Subject: SA.NEXT - SA feedback needed
Message-ID: <52EBB103.5090907@oracle.com>

Hi Everyone,

I would like to start a discussion about future of hotspot debugger,
known as serviceability agent or SA.

How you typically use it? What do you expect from it?  What is missed?

Please, share your stories and wishes.

And please, fill the small quiz:

1. How often do you use SA?

2. On what platform do you use SA?

3. Do you use it to analyze life processes or coredumps?

5. What other debuggers do you use to debug hotspot issues

-Dmitry

-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From aleksey.shipilev at oracle.com  Fri Jan 31 07:32:55 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 31 Jan 2014 19:32:55 +0400
Subject: SA.NEXT - SA feedback needed
In-Reply-To: <52EBB103.5090907@oracle.com>
References: <52EBB103.5090907@oracle.com>
Message-ID: <52EBC227.8070200@oracle.com>

On 01/31/2014 06:19 PM, Dmitry Samersoff wrote:
> How you typically use it? What do you expect from it?  What is missed?

I wish for a simple Java API through which I can shove the byte array,
and SA reinterprets it as the particular piece of metadata for the
current VM. Example: read the object header through Unsafe, and get SA
to decode the metadata there. If it is possible right now, then I want
better documentation :)

-Aleksey.


From vladimir.kozlov at oracle.com  Fri Jan 31 08:48:55 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 31 Jan 2014 08:48:55 -0800
Subject: SA.NEXT - SA feedback needed
In-Reply-To: <52EBB103.5090907@oracle.com>
References: <52EBB103.5090907@oracle.com>
Message-ID: <52EBD3F7.2010307@oracle.com>

It is become more useful for compiler group after ReplayCompilation changes were added into jdk8 to replay crash during 
JIT compilation. SA helps extract replay info and application classes from core files.

Most annoying thing is when you get a core file from customer and you can't open it with SA because on your system 
thread and/or other sys libs is slightly different (other version).

An other thing is how SA knows about Hotspot structures. Very often we change our internal Hotspot classes and forgot to 
update vmStructures. It would be nice to automate it or at least catch the miss during VM/SA build.

Used it on linux, solaris-x86 and -sparc. Never on windows.

Debuggers: dbx on solaris, gdb on others.

Thanks,
Vladimir

On 1/31/14 6:19 AM, Dmitry Samersoff wrote:
> Hi Everyone,
>
> I would like to start a discussion about future of hotspot debugger,
> known as serviceability agent or SA.
>
> How you typically use it? What do you expect from it?  What is missed?
>
> Please, share your stories and wishes.
>
> And please, fill the small quiz:
>
> 1. How often do you use SA?
>
> 2. On what platform do you use SA?
>
> 3. Do you use it to analyze life processes or coredumps?
>
> 5. What other debuggers do you use to debug hotspot issues
>
> -Dmitry
>

From coleen.phillimore at oracle.com  Fri Jan 31 11:52:17 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 31 Jan 2014 14:52:17 -0500
Subject: RFR: 8033057: clang: friend declaration specifying a default
	argument must be a definition
In-Reply-To: <52EAD829.1090506@oracle.com>
References: <52EAD829.1090506@oracle.com>
Message-ID: <52EBFEF1.3090602@oracle.com>


Henry,
This seems fine but you need to check these changes into one of the 
hotspot team repositories, ie: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot
through JPRT.   Let me know if you have any questions.
Thanks,
Coleen

On 1/30/14 5:54 PM, Henry Jen wrote:
> Hi,
>
> Please review a fix on an error reported by clang 3.4.
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8033057/webrev/
>
> The fix is to be comforming to C++ 11 spec, quoted,
>
> C++11: ?8.3.6.4
> "If a friend declaration specifies a default argument expression,
> that declaration shall be a definition and shall be the only declaration
> of the function or function template in the translation unit."
>
> A working draft for C++ 11 can be found at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf
>
> Cheers,
> Henry


From rednaxelafx at gmail.com  Fri Jan 31 12:14:58 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Fri, 31 Jan 2014 12:14:58 -0800
Subject: SA.NEXT - SA feedback needed
In-Reply-To: <52EBB103.5090907@oracle.com>
References: <52EBB103.5090907@oracle.com>
Message-ID: <CA+cQ+tTCg5sXKMJZV48W+PqSSK28q5Z_CoRfTr3o5zAC0o=ThA@mail.gmail.com>

Hi Dmitry,

Thanks for starting this discussion on SA. I guess I was one of the heavy
users of SA so I'm really happy to see it still being developed.

I used SA a lot when I was doing OpenJDK development, almost on a daily
basis if I needed to do debugging. SA was most valuable for me when
debugging code dumps on the box where the crash happened. I used it mostly
on Linux/x86, and sometimes on Windows/x86/JDK7.

I would also use SA for demonstration and learning purposes.
e.g. I wrote a blog post to demonstrate where Java local variables,
instance fields and static fields were in memory in a running HotSpot VM,
here: http://rednaxelafx.iteye.com/blog/1847971
(the blog post was in Chinese but the code example should explain what I
was doing)
Learning how to use SA was a great way for people to poke the internals of
HotSpot. It worked for me. Some functionality of SA are exposed through the
SA-plugin in VisualVM. I started learning about SA with that plugin.

I also used SA to dump classes at runtime to see what the VM thinks it had
loaded. It helped me debug some class loading issues. It's different from
dumping generated classes before the VM loads them.

The SA API is also useful for writing some one-off tools for custom
scenarios, for both live processes and code dumps. I wrote quite a few of
those, e.g. the ones listed here: http://rednaxelafx.iteye.com/blog/1814429
(Unfortunately some people would like to try and use SA features
in-process, which is not how SA works. It's a out-of-process debugger.
Wrapping an out-of-process SA agent and using it in-process with RPC calls
is a weird way of using SA. I don't really recommend that.)

For debugging live processes, sometimes I prefer using utility functions
from utilities/debug.cpp in gdb, because those allow me to do whatever SA
could (e.g. stack walking of a mixed Java/C stack, printing out a oop,
etc.), plus I could use normal debugger functionalities like modifying
memory, setting breakpoints and stepping through code, which SA can't do. I
know SA started out planning to support modifying memory, setting
breakpoints and stepping code, but those were never implemented and
probably still won't be in the future.

Along the lines of what Vladimir mentioned, I wish more of the SA files
could be automatically generated as a part of the build process of HotSpot,
so that it's less likely to miss changes from the VM. Most SA files that
represent VM data structures can be directly mapped from the declarations
of their VM counterparts, and I know a lot of those files were actually
generated from a script and then manually edited a little bit. I believe
that's how Tom implemented SA for reading C2 IR.

Also, I'd like to see more VM internals exposed to SA. It could mean more
maintenance burden so I'm not really pushing it, but it'd be a lot more
useful if it did.
e.g. A while ago I wrote a little patch to expose vtable and itable layouts
in instanceKlass. If I come around to polish and finish it, I'll send it in
for reviews.

Thanks,
Kris



On Fri, Jan 31, 2014 at 6:19 AM, Dmitry Samersoff <
dmitry.samersoff at oracle.com> wrote:

> Hi Everyone,
>
> I would like to start a discussion about future of hotspot debugger,
> known as serviceability agent or SA.
>
> How you typically use it? What do you expect from it?  What is missed?
>
> Please, share your stories and wishes.
>
> And please, fill the small quiz:
>
> 1. How often do you use SA?
>
> 2. On what platform do you use SA?
>
> 3. Do you use it to analyze life processes or coredumps?
>
> 5. What other debuggers do you use to debug hotspot issues
>
> -Dmitry
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
>

From alejandro.murillo at oracle.com  Fri Jan 31 12:29:18 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 31 Jan 2014 20:29:18 +0000
Subject: hg: hsx/jdk7u/hotspot: 3 new changesets
Message-ID: <20140131202924.942876292F@hg.openjdk.java.net>

Changeset: cff7d6378568
Author:    katleman
Date:      2014-01-22 12:33 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/cff7d6378568

Added tag jdk7u60-b04 for changeset 05fe7a87d149

! .hgtags

Changeset: f52b5452d424
Author:    amurillo
Date:      2014-01-31 10:53 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f52b5452d424

Merge

- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 462db155547e
Author:    amurillo
Date:      2014-01-31 10:54 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/462db155547e

Added tag hs24.60-b08 for changeset f52b5452d424

! .hgtags


From calvin.cheung at oracle.com  Fri Jan 31 14:45:15 2014
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 31 Jan 2014 14:45:15 -0800
Subject: RFR: 8032010: Attempt to resolve abstract method in concrete class
	fails with AbstractMethodError
Message-ID: <52EC277B.3070605@oracle.com>

This change, by removing a check in LinkResolver::resolve_method(), is 
to conform with the recent change in JVMS-8 [1].
The following check during method resolution is removed:
JVMS-5.4.3.3. Method Resolution
"If method lookup succeeds and the method is abstract, but C is not 
abstract, method resolution throws an AbstractMethodError."

bug: https://bugs.openjdk.java.net/browse/JDK-8032010

webrev: http://cr.openjdk.java.net/~ccheung/8032010/webrev/

tests: (on linux-x64)
     vm.quick
     jck vm and lang
     jtreg on java/util/stream and the new testcase
     defmeth
     jprt

thanks,
Calvin

[1] http://cr.openjdk.java.net/~dlsmith/jsr335-0.9.1.html#J

From alejandro.murillo at oracle.com  Fri Jan 31 15:15:11 2014
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 31 Jan 2014 23:15:11 +0000
Subject: hg: hsx/jdk7u/hotspot: 8032986: new hotspot build - hs24.60-b09
Message-ID: <20140131231516.DE7A162932@hg.openjdk.java.net>

Changeset: b92f390febd0
Author:    amurillo
Date:      2014-01-31 11:07 -0800
URL:       http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b92f390febd0

8032986: new hotspot build - hs24.60-b09
Reviewed-by: jcoomes

! make/hotspot_version


From alejandro.murillo at oracle.com  Fri Jan 31 15:51:17 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 31 Jan 2014 16:51:17 -0700
Subject: New hotspot repo for 7u60 changes
Message-ID: <52EC36F5.9020208@oracle.com>

Starting immediately, any hotspot change destined for 7u60 should go to:

hg.openjdk.java.net/hsx/jdk7u60/hotspot

These repos may not be available until the end of  the day today

This means that hg.openjdk.java.net/hsx/jdk7u/ is now associated to 7u80,
so any hotspot change destined to 7u80 should be pushed to that repo.

As usual do not hesitate to ask if you have any question
thanks

-- 
Alejandro


From serguei.spitsyn at oracle.com  Fri Jan 31 18:58:21 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 31 Jan 2014 18:58:21 -0800
Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(),
	"cur_stack_depth out of sync")
Message-ID: <52EC62CD.8000300@oracle.com>

Please, review the fix for:
   https://bugs.openjdk.java.net/browse/JDK-6471769


Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/

Summary:

   There is a general issue in the suspend equivalent condition mechanism:
   Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may 
return different results:
     - 1-st: true
     - 2-nd: false

   This more generic suspend equivalent issue is covered by another bug:
     https://bugs.openjdk.java.net/browse/JDK-6280037

   The bug to fix in this review is a specific manifestation of the 6280037
   in the JVMTI GetFrameCount() that has a big impact on the SQE nightly.
   It is on the Test Stabilization radar (as well as the 6280037).
   There are many tests intermittently failing because of this.

   The webrev for review is a one-liner work around the 6280037 for the 
GetFrameCount().

   The JVMTI GetFrameCount() spec tells:
     "If this function is called for a thread actively executing 
bytecodes (for example,
      not the current thread and not suspended), the information 
returned is transient."

   So, it is Ok to call the GetFrameCount() for non-suspended target 
threads.
   To achieve safety, the frame count for non-suspended threads is 
calculated at a safepoint.
   It should be Ok and more safe to do the same for suspended threads as 
well.
   There is no big performance impact because it is already on a slow path.
   It is still important to avoid safepointing when the target thread is 
current.

   The bug 6280037 should go out of the Test Stabilization radar (remove 
the svc-nightly label)
   as the most of the impacted tests are covered by the 6471769.


Testing:
   In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests


Thanks,
Serguei


From christian.thalinger at oracle.com  Fri Jan 31 20:11:59 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 31 Jan 2014 20:11:59 -0800
Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth ==
	count_frames(), "cur_stack_depth out of sync")
In-Reply-To: <52EC62CD.8000300@oracle.com>
References: <52EC62CD.8000300@oracle.com>
Message-ID: <69A2D902-EBD5-4932-A9C1-E8063CB935B7@oracle.com>

I cannot comment on the performance impact but the change looks good.

On Jan 31, 2014, at 6:58 PM, serguei.spitsyn at oracle.com wrote:

> Please, review the fix for:
>  https://bugs.openjdk.java.net/browse/JDK-6471769
> 
> 
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/
> 
> Summary:
> 
>  There is a general issue in the suspend equivalent condition mechanism:
>  Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results:
>    - 1-st: true
>    - 2-nd: false
> 
>  This more generic suspend equivalent issue is covered by another bug:
>    https://bugs.openjdk.java.net/browse/JDK-6280037
> 
>  The bug to fix in this review is a specific manifestation of the 6280037
>  in the JVMTI GetFrameCount() that has a big impact on the SQE nightly.
>  It is on the Test Stabilization radar (as well as the 6280037).
>  There are many tests intermittently failing because of this.
> 
>  The webrev for review is a one-liner work around the 6280037 for the GetFrameCount().
> 
>  The JVMTI GetFrameCount() spec tells:
>    "If this function is called for a thread actively executing bytecodes (for example,
>     not the current thread and not suspended), the information returned is transient."
> 
>  So, it is Ok to call the GetFrameCount() for non-suspended target threads.
>  To achieve safety, the frame count for non-suspended threads is calculated at a safepoint.
>  It should be Ok and more safe to do the same for suspended threads as well.
>  There is no big performance impact because it is already on a slow path.
>  It is still important to avoid safepointing when the target thread is current.
> 
>  The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label)
>  as the most of the impacted tests are covered by the 6471769.
> 
> 
> Testing:
>  In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests
> 
> 
> Thanks,
> Serguei
> 


From serguei.spitsyn at oracle.com  Fri Jan 31 21:43:04 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 31 Jan 2014 21:43:04 -0800
Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth ==
	count_frames(), "cur_stack_depth out of sync")
In-Reply-To: <69A2D902-EBD5-4932-A9C1-E8063CB935B7@oracle.com>
References: <52EC62CD.8000300@oracle.com>
	<69A2D902-EBD5-4932-A9C1-E8063CB935B7@oracle.com>
Message-ID: <52EC8968.20902@oracle.com>

Thanks, Christian!
Serguei

On 1/31/14 8:11 PM, Christian Thalinger wrote:
> I cannot comment on the performance impact but the change looks good.
>
> On Jan 31, 2014, at 6:58 PM, serguei.spitsyn at oracle.com wrote:
>
>> Please, review the fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-6471769
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/
>>
>> Summary:
>>
>>   There is a general issue in the suspend equivalent condition mechanism:
>>   Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results:
>>     - 1-st: true
>>     - 2-nd: false
>>
>>   This more generic suspend equivalent issue is covered by another bug:
>>     https://bugs.openjdk.java.net/browse/JDK-6280037
>>
>>   The bug to fix in this review is a specific manifestation of the 6280037
>>   in the JVMTI GetFrameCount() that has a big impact on the SQE nightly.
>>   It is on the Test Stabilization radar (as well as the 6280037).
>>   There are many tests intermittently failing because of this.
>>
>>   The webrev for review is a one-liner work around the 6280037 for the GetFrameCount().
>>
>>   The JVMTI GetFrameCount() spec tells:
>>     "If this function is called for a thread actively executing bytecodes (for example,
>>      not the current thread and not suspended), the information returned is transient."
>>
>>   So, it is Ok to call the GetFrameCount() for non-suspended target threads.
>>   To achieve safety, the frame count for non-suspended threads is calculated at a safepoint.
>>   It should be Ok and more safe to do the same for suspended threads as well.
>>   There is no big performance impact because it is already on a slow path.
>>   It is still important to avoid safepointing when the target thread is current.
>>
>>   The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label)
>>   as the most of the impacted tests are covered by the 6471769.
>>
>>
>> Testing:
>>   In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests
>>
>>
>> Thanks,
>> Serguei
>>